[OpenSIPS-Users] [OpenSIPS-Devel] [RFC] New Release Policy for OpenSIPS project

[Bogdan-Andrei Iancu]

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 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>
>     On 11/30/2012 07:24 PM, Ryan Bullock wrote:
>>     On Mon, Nov 26, 2012 at 1:57 PM, Bogdan-Andrei Iancu
>>     <bogdan at opensips.org <mailto:bogdan at opensips.org>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121211/b2b288cf/attachment.htm>