[RFC] New Release Policy for OpenSIPS project

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] New Release Policy for OpenSIPS project

Bogdan-Andrei Iancu-2
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Saúl Ibarra Corretgé
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Bogdan-Andrei Iancu-2
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Saúl Ibarra Corretgé
Hi,

> 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.
>

I agree that is good for bugfix releases. However, when planning the next release (lets say 1.10) I guess you'd plan what features are to be implemented. Then of course time needs to be weighted in the equation, but IMHO the time constraint should be a bit more loose for major releases.

>
> PS: let me ask you: how many OpenSIPS installations do you still have running old versions because upgrade is really painful ? ;)

Fortunately not many :-) I had to migrate from 1.4 to 1.8 and, well, things can get complicated. Of course the gap is big and wouldn't be so big between 1.7 and 1.8 or between 1.8 and 1.9, but updating requires time and a reason. If a customer has a working OpenSIPS version and I update it just for the sake of it, new bugs can be introduced, and he'll probably not see any of the new features because he doesn't need them, for example. This is what I mean by not taking it lightly.

[snip]

>> 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.

New versions have new features and new bugs. So updating may get you trouble for little gain, in case you are not using any of the new stuff.

>    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....
>

Not 100% accurate: -) "The security team tries to support a stable distribution for about one year after the next stable distribution has been released". So Debian "oldstable" still gets security updates a year after "stable" has been out.

We can try to see how a similar approach can work out for us. Instead of a year, say 6 months. What's important is to define what a security fix is and what it's not. An error in the software that can be consistently triggered from the outside (ie, with SIP traffic) and cause any kind of outage could be considered a security fix. This is from the top of my head, it would need to be refined :-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Ali Pey
Hi Bogdan,

This is great to see and I quite like the more open, predictable and transparent approach. I also agree that a time driven release cycle is more practical than feature driven. There are always grey areas and exceptions but in practice a time driven release cycle is much better manageable for real world deployments.

In terms of support for previous releases, as much as it would allow a deployment to go on for two years before it requires an upgrade I agree. It's not practical to have more frequent upgrade cycles. Also most people don't usually upgrade to the latest version. For instance when 1.9 comes out, we probably will upgrade to 1.8.2.

Again, this is a great step forward for opensips development and thank you for the great work.

Regards,
Ali Pey
 


On Fri, Nov 23, 2012 at 4:36 AM, Saúl Ibarra Corretgé <[hidden email]> wrote:
Hi,

> 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.
>

I agree that is good for bugfix releases. However, when planning the next release (lets say 1.10) I guess you'd plan what features are to be implemented. Then of course time needs to be weighted in the equation, but IMHO the time constraint should be a bit more loose for major releases.

>
> PS: let me ask you: how many OpenSIPS installations do you still have running old versions because upgrade is really painful ? ;)

Fortunately not many :-) I had to migrate from 1.4 to 1.8 and, well, things can get complicated. Of course the gap is big and wouldn't be so big between 1.7 and 1.8 or between 1.8 and 1.9, but updating requires time and a reason. If a customer has a working OpenSIPS version and I update it just for the sake of it, new bugs can be introduced, and he'll probably not see any of the new features because he doesn't need them, for example. This is what I mean by not taking it lightly.

[snip]

>> 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.

New versions have new features and new bugs. So updating may get you trouble for little gain, in case you are not using any of the new stuff.

>    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....
>

Not 100% accurate: -) "The security team tries to support a stable distribution for about one year after the next stable distribution has been released". So Debian "oldstable" still gets security updates a year after "stable" has been out.

We can try to see how a similar approach can work out for us. Instead of a year, say 6 months. What's important is to define what a security fix is and what it's not. An error in the software that can be consistently triggered from the outside (ie, with SIP traffic) and cause any kind of outage could be considered a security fix. This is from the top of my head, it would need to be refined :-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Brett Nemeroff
In reply to this post by Bogdan-Andrei Iancu-2

On Thu, Nov 22, 2012 at 4:34 AM, Bogdan-Andrei Iancu <[hidden email]> 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.



 Just my two cents here...

With regards to the release cycle... I typically find myself doing "production" deployments for my clients. What I need is a stable version. And then hotfixes as bugs are discovered. 

I prefer feature driven releases because I can look forward to when feature X will be available. My production deployments typically run untouched while in production mode. Upgrades occur when new features are needed AND available in stable builds. I don't typically upgrade simply because an upgrade is available. Of course, I'll normally upgrade for critical fixes or security fixes (which I'd see as a hotfix typically and not a full release)

If I knew a release was going to be available on a particular date, I would without question start reviewing that release and it's new capabilities; but I wouldn't need it for a production build. 

If I knew a feature was available on a certain date, I could pitch that to my clients if it was a feature they might need. Also, I'm afraid that time based releases may rush features out before they are ready.

That's just my perspective based on my workflow. I'm sure there are others that feel differently. :)
-Brett



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Jeff Pyle
On Sun, Nov 25, 2012 at 10:32 AM, Brett Nemeroff <[hidden email]> wrote:

 Just my two cents here...

With regards to the release cycle... I typically find myself doing "production" deployments for my clients. What I need is a stable version. And then hotfixes as bugs are discovered. 

I prefer feature driven releases because I can look forward to when feature X will be available. My production deployments typically run untouched while in production mode. Upgrades occur when new features are needed AND available in stable builds. I don't typically upgrade simply because an upgrade is available. Of course, I'll normally upgrade for critical fixes or security fixes (which I'd see as a hotfix typically and not a full release)

If I knew a release was going to be available on a particular date, I would without question start reviewing that release and it's new capabilities; but I wouldn't need it for a production build. 

If I knew a feature was available on a certain date, I could pitch that to my clients if it was a feature they might need. Also, I'm afraid that time based releases may rush features out before they are ready.

That's just my perspective based on my workflow. I'm sure there are others that feel differently. :)
-Brett


I, for one, share Brett's perspective.


- Jeff


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Bogdan-Andrei Iancu-2
In reply to this post by Ali Pey
Hi Ali,

Thanks for feedback - regarding the support for previous releases, Saul raised the same point as you, and I have to admit I didn't do the math - 2 release ~= 1 year, which indeed is too short - I mean this will force an upgrade each year.

So, we need to somehow get to ~ 2 year lifetime for a release. My suggestion is to actually set a life span for 2 years.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 11/25/2012 04:22 PM, Ali Pey wrote:
Hi Bogdan,

This is great to see and I quite like the more open, predictable and transparent approach. I also agree that a time driven release cycle is more practical than feature driven. There are always grey areas and exceptions but in practice a time driven release cycle is much better manageable for real world deployments.

In terms of support for previous releases, as much as it would allow a deployment to go on for two years before it requires an upgrade I agree. It's not practical to have more frequent upgrade cycles. Also most people don't usually upgrade to the latest version. For instance when 1.9 comes out, we probably will upgrade to 1.8.2.

Again, this is a great step forward for opensips development and thank you for the great work.

Regards,
Ali Pey
 


On Fri, Nov 23, 2012 at 4:36 AM, Saúl Ibarra Corretgé <[hidden email]> wrote:
Hi,

> 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.
>

I agree that is good for bugfix releases. However, when planning the next release (lets say 1.10) I guess you'd plan what features are to be implemented. Then of course time needs to be weighted in the equation, but IMHO the time constraint should be a bit more loose for major releases.

>
> PS: let me ask you: how many OpenSIPS installations do you still have running old versions because upgrade is really painful ? ;)

Fortunately not many :-) I had to migrate from 1.4 to 1.8 and, well, things can get complicated. Of course the gap is big and wouldn't be so big between 1.7 and 1.8 or between 1.8 and 1.9, but updating requires time and a reason. If a customer has a working OpenSIPS version and I update it just for the sake of it, new bugs can be introduced, and he'll probably not see any of the new features because he doesn't need them, for example. This is what I mean by not taking it lightly.

[snip]

>> 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.

New versions have new features and new bugs. So updating may get you trouble for little gain, in case you are not using any of the new stuff.

>    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....
>

Not 100% accurate: -) "The security team tries to support a stable distribution for about one year after the next stable distribution has been released". So Debian "oldstable" still gets security updates a year after "stable" has been out.

We can try to see how a similar approach can work out for us. Instead of a year, say 6 months. What's important is to define what a security fix is and what it's not. An error in the software that can be consistently triggered from the outside (ie, with SIP traffic) and cause any kind of outage could be considered a security fix. This is from the top of my head, it would need to be refined :-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Bogdan-Andrei Iancu-2
In reply to this post by Jeff Pyle
Hi,

Your arguments are actually supporting more the time-based cycles :). Keep in mind that all the time a new release will be a set of new features, so basically all releases are also featured driven. But to make it more predictable, we consider some time limits (for a release cycle) - limits are quite large 5 to 7 months, so we have flexibility to fit various sets of features in that interval. The main idea with time-based cycles is to try to control how long will take for have the next release (more predictable, without large gaps between releases) and also to speed up the features delivery (having a faster cycle, features will be available in stable versions quicker).

Let me know if I missed some your points or if my thinking is wrong.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 11/26/2012 04:02 PM, Jeff Pyle wrote:
On Sun, Nov 25, 2012 at 10:32 AM, Brett Nemeroff <[hidden email]> wrote:

 Just my two cents here...

With regards to the release cycle... I typically find myself doing "production" deployments for my clients. What I need is a stable version. And then hotfixes as bugs are discovered. 

I prefer feature driven releases because I can look forward to when feature X will be available. My production deployments typically run untouched while in production mode. Upgrades occur when new features are needed AND available in stable builds. I don't typically upgrade simply because an upgrade is available. Of course, I'll normally upgrade for critical fixes or security fixes (which I'd see as a hotfix typically and not a full release)

If I knew a release was going to be available on a particular date, I would without question start reviewing that release and it's new capabilities; but I wouldn't need it for a production build. 

If I knew a feature was available on a certain date, I could pitch that to my clients if it was a feature they might need. Also, I'm afraid that time based releases may rush features out before they are ready.

That's just my perspective based on my workflow. I'm sure there are others that feel differently. :)
-Brett


I, for one, share Brett's perspective.


- Jeff

_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Bogdan-Andrei Iancu-2
In reply to this post by Saúl Ibarra Corretgé
Hi Saul,

On 11/23/2012 11:36 AM, Saúl Ibarra Corretgé wrote:
> Hi,
>
>> 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.
>>
> I agree that is good for bugfix releases. However, when planning the next release (lets say 1.10) I guess you'd plan what features are to be implemented. Then of course time needs to be weighted in the equation, but IMHO the time constraint should be a bit more loose for major releases.
[bogdan]
copying from another answer of mine: Keep in mind that all the time a
new release will be a set of new features, so basically all releases are
also featured driven. But to make it more predictable, we consider some
time limits (for a release cycle) - limits are quite large 5 to 7
months, so we have flexibility to fit various sets of features in that
interval. The main idea with time-based cycles is to try to control how
long will take for have the next release (more predictable, without
large gaps between releases) and also to speed up the features delivery
(having a faster cycle, features will be available in stable versions
quicker).

>
> 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.
> New versions have new features and new bugs. So updating may get you trouble for little gain, in case you are not using any of the new stuff.
>
>>     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....
>>
> Not 100% accurate: -) "The security team tries to support a stable distribution for about one year after the next stable distribution has been released". So Debian "oldstable" still gets security updates a year after "stable" has been out.
>
> We can try to see how a similar approach can work out for us. Instead of a year, say 6 months. What's important is to define what a security fix is and what it's not. An error in the software that can be consistently triggered from the outside (ie, with SIP traffic) and cause any kind of outage could be considered a security fix. This is from the top of my head, it would need to be refined :-)
[bogdan]
again, copying from another answer of mine: I have to admit I didn't do
the math - 2 release ~= 1 year, which indeed is too short - I mean this
will force an upgrade each year. So, we need to somehow get to ~ 2 year
lifetime for a release. My suggestion is to actually set a life span for
2 years.


Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Saúl Ibarra Corretgé
Hi Bogdan,

> copying from another answer of mine: Keep in mind that all the time a new release will be a set of new features, so basically all releases are also featured driven. But to make it more predictable, we consider some time limits (for a release cycle) - limits are quite large 5 to 7 months, so we have flexibility to fit various sets of features in that interval. The main idea with time-based cycles is to try to control how long will take for have the next release (more predictable, without large gaps between releases) and also to speed up the features delivery (having a faster cycle, features will be available in stable versions quicker).

Ok, so it's more of a hybrid thing. In that case I'd be k with it, if we allow for some flexibility in case we were a bit too optimistic with the planning ;-)

[snip]

>
> again, copying from another answer of mine: I have to admit I didn't do the math - 2 release ~= 1 year, which indeed is too short - I mean this will force an upgrade each year. So, we need to somehow get to ~ 2 year lifetime for a release. My suggestion is to actually set a life span for 2 years.
>

2 years sounds about right.

Thanks for doing this in the Open, Bogdan :-)

Kind regards,

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Yuming Zheng
In reply to this post by Bogdan-Andrei Iancu-2
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 <[hidden email]>
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New Release Policy for OpenSIPS project

Bogdan-Andrei Iancu-2
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 <[hidden email]>
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RFC] New Release Policy for OpenSIPS project

Ryan Bullock
In reply to this post by Bogdan-Andrei Iancu-2
On Mon, Nov 26, 2012 at 1:57 PM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Hi Ali,

Thanks for feedback - regarding the support for previous releases, Saul raised the same point as you, and I have to admit I didn't do the math - 2 release ~= 1 year, which indeed is too short - I mean this will force an upgrade each year.

So, we need to somehow get to ~ 2 year lifetime for a release. My suggestion is to actually set a life span for 2 years.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
What about adding a long term support branch that is released every two years and supported for 2 years, and then a release every 6 months for 'standard' releases. Each standard release would be supported for 1 year.

Something like this, assuming 1.10 is the first long term support:
1.10 - Long term support (2 years)
1.11 - Standard release (1 year)
1.12 - Standard release (1 year)
1.13 - Standard release (1 year)
1.14 - Long term support (2 years)

Those wanting new features can go for the standard releases, and those looking for stability and better support can stick with the long term support releases. It should strike a decent balance between getting features out the door and support.

Just a thought.

Regards,

Ryan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RFC] New Release Policy for OpenSIPS project

Ali Pey
I agree with this. Not every release needs to be supported for a full 2 years. 

Regards,
Ali Pey



On Fri, Nov 30, 2012 at 12:24 PM, Ryan Bullock <[hidden email]> wrote:
On Mon, Nov 26, 2012 at 1:57 PM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Hi Ali,

Thanks for feedback - regarding the support for previous releases, Saul raised the same point as you, and I have to admit I didn't do the math - 2 release ~= 1 year, which indeed is too short - I mean this will force an upgrade each year.

So, we need to somehow get to ~ 2 year lifetime for a release. My suggestion is to actually set a life span for 2 years.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
What about adding a long term support branch that is released every two years and supported for 2 years, and then a release every 6 months for 'standard' releases. Each standard release would be supported for 1 year.

Something like this, assuming 1.10 is the first long term support:
1.10 - Long term support (2 years)
1.11 - Standard release (1 year)
1.12 - Standard release (1 year)
1.13 - Standard release (1 year)
1.14 - Long term support (2 years)

Those wanting new features can go for the standard releases, and those looking for stability and better support can stick with the long term support releases. It should strike a decent balance between getting features out the door and support.

Just a thought.

Regards,

Ryan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RFC] New Release Policy for OpenSIPS project

Bogdan-Andrei Iancu-2
In reply to this post by Ryan Bullock

On 11/30/2012 07:24 PM, Ryan Bullock wrote:
On Mon, Nov 26, 2012 at 1:57 PM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Hi Ali,

Thanks for feedback - regarding the support for previous releases, Saul raised the same point as you, and I have to admit I didn't do the math - 2 release ~= 1 year, which indeed is too short - I mean this will force an upgrade each year.

So, we need to somehow get to ~ 2 year lifetime for a release. My suggestion is to actually set a life span for 2 years.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
What about adding a long term support branch that is released every two years and supported for 2 years, and then a release every 6 months for 'standard' releases. Each standard release would be supported for 1 year.

Something like this, assuming 1.10 is the first long term support:
1.10 - Long term support (2 years)
1.11 - Standard release (1 year)
1.12 - Standard release (1 year)
1.13 - Standard release (1 year)
1.14 - Long term support (2 years)

Those wanting new features can go for the standard releases, and those looking for stability and better support can stick with the long term support releases. It should strike a decent balance between getting features out the door and support.
Hi Ryan,

By doing that  ^^^ it means not all releases will be alike (and the so-far assumption is that all major release are alike) - or I'm missing something here.

I like this approach as this will imply less maintaining work for developers :), but I dislike it as it will more difficult to understand and upgrade (for users).
Do you know any project using something like that ?

Thanks and regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RFC] New Release Policy for OpenSIPS project

Bogdan-Andrei Iancu-2
Hi Ryan,

Thanks for this - to be honest it looks really interesting from my perspective. Personally I would love to go with something like this.

All releases to be alike from how they are built. But to have 2 types of releases when comes to maintaining them:
    - LTS - supported like 2 years or more.
    - STS - supported up to the next release or so.

Considering that most of work on packing, maintaining, etc will be done for LTS (as you suggested), this will reduce the work for developers, but giving more flexibility to the users.

Shortly, I like it and I would like to go for it. Any other comments on this ? Or drawbacks here ?

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 12/04/2012 08:41 PM, Ryan Bullock wrote:
Hey Bogdan,

Off the top of my head, Asterisk and Ubuntu use a release schedule similar schedule to what I described. Both have a long term support releases as well as a standard releases. I think it is a good fit for a fairly fast moving project.

You are correct that not all releases will be alike, but the user can choose their release track. Long term for those who want to do a deployment and still get bug/security fixes without having to worry about breakage between upgrades. Standard for those looking to get their hands on new features as they become available.

If it is very clear as to what is the current long term supported and what is the current standard release (and their differences) on the website I don't see it as an issue. Any potential issues can be lessened ever further if there is always a clear upgrade path/plan (same as what you do now for migration instructions between versions) from the current LTS to the current standard. Then users can always start on the LTS and move to the standard if they need to take advantage of a new feature.

I think something like this is important for a time release schedule, otherwise the number of supported branches might really start to stack up. The other benefit is that this may work better for packagers (e.g. for debian or rhel). They can just package the LTS version and it would make it easier on them and the users (less chance of surprise breakage after an update).

This release schedule on top of going to time release I think would be great as there is something for everyone without (hopefully) overloading the developers.

Regards,

Ryan

On Tue, Dec 4, 2012 at 4:57 AM, Bogdan-Andrei Iancu <[hidden email]> wrote:

On 11/30/2012 07:24 PM, Ryan Bullock wrote:
On Mon, Nov 26, 2012 at 1:57 PM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Hi Ali,

Thanks for feedback - regarding the support for previous releases, Saul raised the same point as you, and I have to admit I didn't do the math - 2 release ~= 1 year, which indeed is too short - I mean this will force an upgrade each year.

So, we need to somehow get to ~ 2 year lifetime for a release. My suggestion is to actually set a life span for 2 years.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
What about adding a long term support branch that is released every two years and supported for 2 years, and then a release every 6 months for 'standard' releases. Each standard release would be supported for 1 year.

Something like this, assuming 1.10 is the first long term support:
1.10 - Long term support (2 years)
1.11 - Standard release (1 year)
1.12 - Standard release (1 year)
1.13 - Standard release (1 year)
1.14 - Long term support (2 years)

Those wanting new features can go for the standard releases, and those looking for stability and better support can stick with the long term support releases. It should strike a decent balance between getting features out the door and support.
Hi Ryan,

By doing that  ^^^ it means not all releases will be alike (and the so-far assumption is that all major release are alike) - or I'm missing something here.

I like this approach as this will imply less maintaining work for developers :), but I dislike it as it will more difficult to understand and upgrade (for users).
Do you know any project using something like that ?

Thanks and regards,
Bogdan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users