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

[Saúl Ibarra Corretgé]

Hi Bogdan,

It's great to see this. See some comments inline.

On Nov 22, 2012, at 11:34 AM, Bogdan-Andrei Iancu wrote:

> 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.
> 

While a time-based release cycle sounds good to me for minor releases (1.8.1, 1.8.2, ...) I'm not sure if it can also be applied to major releases. What if feature X takes longer than expected to develop? Things may be inadvertently rushed and that's not good. For major releases I'd go with the Debian-ish policy: it's ready when it's ready :-)

> 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).
> 

What about security fixes? I can understand that when 1.9 is released 1.7 goes to EOL (sort of), but what if there is a bug in the parser (for example) which can cause a crash just by using a stupid script? IMHO there should be a security-fixes-only period, since migrating to a new OpenSIPS version is not  a task to be taken lightly.

Those are my 2 cents.


Kind regards,

--
Saúl Ibarra Corretgé
AG Projects