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

Yuming Zheng zhengyumingnanjing at gmail.com
Fri Nov 30 03:18:18 CET 2012


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>

> **
> 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 Developerhttp://www.opensips-solutions.com
>
>
> _______________________________________________
> 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/bd3ace2e/attachment-0001.htm>


More information about the Users mailing list