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
<bog...@opensips.org <mailto:bog...@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
<bog...@opensips.org <mailto:bog...@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
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
