Hi Frank,
There is a similar page : see http://www.opensips.org/Main/Ver190#toc10
. This page can be edit by whoever has an account on opensips.org web site.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11/30/2012 04:18 AM, Yuming Zheng wrote:
Hi bogdan,
I suggest to have a wish list page for the entire community.
like this: http://microsip.org.ua/wishes//,should help to form the
TODO features and and thank you for the great work.
Best Regard,
Frank.zheng
2012/11/22 Bogdan-Andrei Iancu <[email protected]
<mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
