<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Hi all,<br>
<br>
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.<br>
<br>
First of all, what this change should target? It should make the
release process :<br>
- <b>more open</b> - anyone from community (and not only
developers) should be able to <br>
contribute to roadmap of the next release (on what should
be done)<br>
- <b>more predictable</b> - everyone should know when and how
the next release will be <br>
available, so they can rely and sync their own private
schedules (for using opensips)<br>
with the project scheduling. You will know when the next
release will be available <br>
as RC, as GA, etc, you will know what features will
contain, you will know when to <br>
get involved for bringing in discussion some new features
for the next release.<br>
- <b>more transparent</b> - the entire releasing process to
be generally known in details, so<br>
we can achieve a better collaboration and interfacing
between community and developers<br>
(we should avoid a separation between these two entities
and rather put them together <br>
to work)<br>
<br>
<br>
Now, </tt><tt>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.</tt><tt><br>
<br>
Release cycles<br>
===============<br>
- 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<br>
- have a 5-7 months release cycle (depending on the required
volume of work)<br>
- 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.<br>
<br>
Next Release TODO<br>
==================<br>
- 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.<br>
- 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 <a class="moz-txt-link-freetext" href="http://www.opensips.org/Main/Ver190">http://www.opensips.org/Main/Ver190</a>)<br>
- 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.<br>
<br>
Steps inside a Cycle<br>
====================<br>
- brainstorming on TODO list<br>
- estimating the release time (T) based on the volume of work
(between 5-7 months)<br>
- actual work on implementing the items on TODO list ; it is
critical important to have a <br>
better description / documentation / examples on the newly
added feature -> it will help<br>
people to understand and use them from day 0 (an
undocumented super feature is an <br>
inexistent feature)<br>
- SVN freeze (no more new stuff) at T - 1 months ; at this
point the SVN trunk code <br>
is moved in a new separate SVN branch (dedicated to that
release)-> Release Candidate <br>
(or beta release) ; this will make the trunk free and
available for new work in the <br>
mean while (we overlap the testing on release N with the
start of release N+1)<br>
- testing, debugging - 1 month -> at T we have the GA
release (full stable release)<br>
<br>
Version Management<br>
==================<br>
- at any moment, officially we will support only the last 2
stable release (by support I mean <br>
troubleshooting, fixing bugs, backporting, etc)<br>
- whatever is older than 2 stable release (like older than 1.7
now) is unsupported (no fixing,<br>
no packing, no new tarballs)<br>
- when a new release gets to a full stable state, the window
of 2 supported versions is shifted<br>
(like when 1.9 will become stable, 1.7 will become
obsolete and unsupported).<br>
<br>
<br>
<br>
Regards,<br>
</tt>
<pre class="moz-signature" cols="72">--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
</body>
</html>