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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
