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 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
