[OpenSIPS-Users] [RFC] New Release Policy for OpenSIPS project

[Bogdan-Andrei Iancu]

Hi Frank,

There is a similar page : see http://www.opensips.org/Main/Ver190#toc10 
. This page can be edit by whoever has an account on opensips.org web site.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/30/2012 04:18 AM, Yuming Zheng wrote:
> Hi bogdan,
>
>   I suggest to have a wish list page for the entire community.
> like this: http://microsip.org.ua/wishes//,should help to form the 
> TODO features and and thank you for the great work.
>
> Best Regard,
>
> Frank.zheng
>
>
> 2012/11/22 Bogdan-Andrei Iancu <bogdan at opensips.org 
> <mailto:bogdan at opensips.org>>
>
>     Hi all,
>
>     I want to bring to public discussion the changing of the release
>     policy of the project. Why, because I had an interesting feedback
>     from the community after the email on shaping the 1.9 release and
>     I felt the need of straighting some things up.
>
>     First of all, what this change should target? It should make the
>     release process :
>         - *more open* - anyone from community (and not only
>     developers) should be able to
>             contribute to roadmap of the next release (on what should
>     be done)
>         - *more predictable* - everyone should know when and how the
>     next release will be
>             available, so they can rely and sync their own private
>     schedules (for using opensips)
>             with the project scheduling. You will know when the next
>     release will be available
>             as RC, as GA, etc, you will know what features will
>     contain, you will know when to
>             get involved for bringing in discussion some new features
>     for the next release.
>         - *more transparent* - the entire releasing process to be
>     generally known in details, so
>             we can achieve a better collaboration and interfacing
>     between community and developers
>             (we should avoid a separation between these two entities
>     and rather put them together
>             to work)
>
>
>     Now, I'm listing here what I see as a starting point and I'm eager
>     to hear your comments, suggestions, improvements or any other
>     ideas related to this topic.
>
>     Release cycles
>     ===============
>         - instead of a feature driven release cycle, I would prefer a
>     time driven release cycle - because it is more predictable and
>     being feature driven may actually escalate the time to the next
>     release (the snowball effect) - see the timing for 1.7, 1.8 versions
>         - have a 5-7 months release cycle (depending on the required
>     volume of work)
>         - smaller steps in releases will be more friendly to users as
>     there are no big gaps between releases, easier and more appealing
>     to upgrade ; also shorter release cycles will make new features
>     available in stable versions much faster.
>
>     Next Release TODO
>     ==================
>         - on a new cycle, we should start with a brainstorming on what
>     the next release should contain (or focus on). This will open up
>     the development and roadmap of the project to the entire community.
>         - maintain a web page with the TODO features that will be
>     updated (this process is to be continuous); also the items that
>     where address to be documented and listed as new available
>     features (see http://www.opensips.org/Main/Ver190)
>         - as the release is time driven, the next release will contain
>     only the features (from TODO list, based on priorities) that can
>     be done in that time frame; the remaining list will be inherited
>     by the next release.
>
>     Steps inside a Cycle
>     ====================
>         - brainstorming on TODO list
>         - estimating the release time (T) based on the volume of work
>     (between 5-7 months)
>         - actual work on implementing the items on TODO list ; it is
>     critical important to have a
>             better description / documentation / examples on the newly
>     added feature -> it will help
>             people to understand and use them from day 0 (an
>     undocumented super feature is an
>             inexistent feature)
>         - SVN freeze (no more new stuff) at T - 1 months ; at this
>     point the SVN trunk code
>             is moved in a new separate SVN branch (dedicated to that
>     release)-> Release Candidate
>             (or beta release) ; this will make the trunk free and
>     available for new work in the
>             mean while (we overlap the testing on release N with the
>     start of release N+1)
>         - testing, debugging - 1 month -> at T we have the GA release
>     (full stable release)
>
>     Version Management
>     ==================
>         - at any moment, officially we will support only the last 2
>     stable release (by support I mean
>             troubleshooting, fixing bugs, backporting, etc)
>         - whatever is older than 2 stable release (like older than 1.7
>     now) is unsupported (no fixing,
>             no packing, no new tarballs)
>         - when a new release gets to a full stable state, the window
>     of 2 supported versions is shifted
>             (like when 1.9 will become stable, 1.7 will become
>     obsolete and unsupported).
>
>
>
>     Regards,
>
>     -- 
>     Bogdan-Andrei Iancu
>     OpenSIPS Founder and Developer
>     http://www.opensips-solutions.com
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121130/b6f855d1/attachment.htm>