Hi Saul,
On 11/22/2012 12:46 PM, Saúl Ibarra Corretgé wrote:
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 :-)
[bogdan]
The problem I see with the features-based release cycle is that they are
unpredictable as time - some features may not be properly (or
impossible) time evaluated -> it may stretch the interval between
releases ; IMHO, for a project to reliable it is a must to be
predictable. The best examples are what is happening now with OpenSIPS
(the interval between releases is keep growing) and Debian (lack of
predictability and huge intervals between release ended up in the Ubuntu
alternative).
Being able to predict the releases (as time) without huge differences
between versions (to make an upgrade something easy you are not scared
like hell to do it) should be some key-feature of the project.
The time-based releases should not be affected by how long a feature
takes to be implemented - 6 months of development for a feature is
really more than enough, IMHO.
PS: let me ask you: how many OpenSIPS installations do you still have
running old versions because upgrade is really painful ? ;)
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.
[bogdan]
That is true problem that may have as solutions:
1) simply upgrade (most common way to go in open source world) ,
considering that upgrades should become easier.
2) try to define what is really critical (based on what??) and
still do backporting - but at the end of the day we need to encourage
people to use the new versions - keep patching and supporting really old
versions (consider 1.6 at this point) is a waist of effort. Taking your
example: debian is not supporting something older than 1 release :D....
But I'm open to solutions here.
Regards,
Bogdan
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
