Hello,
We're slowly getting ready for a new major release of mediaproxy-ng (3.x), which will include some exciting new features, most importantly much improved support for WebRTC. To support those features, rtpproxy-ng needs to support additional flags for the offer/answer functions.
Since we're slowly running out of flag letters :) we'd like to take this opportunity to revamp the flag handling within the module, break backwards compatibility with the original rtpproxy module interface, and rename both rtpproxy-ng and mediaproxy-ng (starting with version 3.0) to rtpEngine, in an attempt to clean up the unfortunate naming conventions between the two.
So, my question is if there's any particular procedure that should be followed in order to achieve this renaming of a module? Or if it would be better to leave the old module in place and just add a new module?
Cheers
Richard Fuchs writes:
We're slowly getting ready for a new major release of mediaproxy-ng (3.x), which will include some exciting new features, most importantly much improved support for WebRTC. To support those features, rtpproxy-ng needs to support additional flags for the offer/answer functions.
This is great news. In my opinion it would be better to rename rtpproxy-ng module rather than leave its existing version hanging there, because I'm sure that current users of the module will migrate to the new one anyhow.
-- Juha
My vote for the renaming. It is very confusing to have mediaproxy-ng + rtpproxy | rtpproxy-ng modules, when you also have mediaproxy module and rtpproxy-proxy and mediaproxy-proxy, IYKWIM.
Regards,
On Fri, Mar 21, 2014 at 10:15 AM, Juha Heinanen jh@tutpro.com wrote:
Richard Fuchs writes:
We're slowly getting ready for a new major release of mediaproxy-ng (3.x), which will include some exciting new features, most importantly much improved support for WebRTC. To support those features, rtpproxy-ng needs to support additional flags for the offer/answer functions.
This is great news. In my opinion it would be better to rename rtpproxy-ng module rather than leave its existing version hanging there, because I'm sure that current users of the module will migrate to the new one anyhow.
-- Juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2014-03-21 20:04 GMT+04:00 Richard Fuchs rfuchs@sipwise.com:
Since we're slowly running out of flag letters :) we'd like to take this opportunity to revamp the flag handling within the module, break backwards compatibility with the original rtpproxy module interface, and rename both rtpproxy-ng and mediaproxy-ng (starting with version 3.0) to rtpEngine, in an attempt to clean up the unfortunate naming conventions between the two.
Great news! This will simplify a lot of things. Hope you won't use camelCase in the official name :)
On 03/22/14 04:55, Peter Lemenkov wrote:
2014-03-21 20:04 GMT+04:00 Richard Fuchs rfuchs@sipwise.com:
Since we're slowly running out of flag letters :) we'd like to take this opportunity to revamp the flag handling within the module, break backwards compatibility with the original rtpproxy module interface, and rename both rtpproxy-ng and mediaproxy-ng (starting with version 3.0) to rtpEngine, in an attempt to clean up the unfortunate naming conventions between the two.
Great news! This will simplify a lot of things. Hope you won't use camelCase in the official name :)
No camelCase, at least not in the module/function names :D
So how do I go about renaming? Just like that, or should I leave a README in the old directory, pointing to the renamed module, or...?
cheers
On 25/03/14 00:05, Richard Fuchs wrote:
On 03/22/14 04:55, Peter Lemenkov wrote:
2014-03-21 20:04 GMT+04:00 Richard Fuchs rfuchs@sipwise.com:
Since we're slowly running out of flag letters :) we'd like to take this opportunity to revamp the flag handling within the module, break backwards compatibility with the original rtpproxy module interface, and rename both rtpproxy-ng and mediaproxy-ng (starting with version 3.0) to rtpEngine, in an attempt to clean up the unfortunate naming conventions between the two.
Great news! This will simplify a lot of things. Hope you won't use camelCase in the official name :)
No camelCase, at least not in the module/function names :D
So how do I go about renaming? Just like that, or should I leave a README in the old directory, pointing to the renamed module, or...?
Just rename it, don't keep anything from old one in place.
You can use 'git mv ...' to keep the track in the history.
Cheers, Daniel
-
Carlos Ruiz Díaz -
Daniel-Constantin Mierla -
Juha Heinanen -
Peter Lemenkov -
Richard Fuchs