<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Hi Ryan,<br>
<br>
Thanks for this - to be honest it looks really interesting from my
perspective. Personally I would love to go with something like
this.<br>
<br>
All releases to be alike from how they are built. But to have 2
types of releases when comes to maintaining them:<br>
- LTS - supported like 2 years or more.<br>
- STS - supported up to the next release or so.<br>
<br>
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.<br>
<br>
Shortly, I like it and I would like to go for it. Any other
comments on this ? Or drawbacks here ?<br>
<br>
Regards,<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
<br>
On 12/04/2012 08:41 PM, Ryan Bullock wrote:
<blockquote
cite="mid:CAAcj4gUZdqsi6cqRekxDKocGwF9Pmr7WoUyRcAbDpnvuEPB42Q@mail.gmail.com"
type="cite">Hey Bogdan,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
Regards,<br>
<br>
Ryan<br>
<br>
<div class="gmail_quote">
On Tue, Dec 4, 2012 at 4:57 AM, Bogdan-Andrei Iancu <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div>
<div class="h5"> <br>
On 11/30/2012 07:24 PM, Ryan Bullock wrote:
<blockquote type="cite">On Mon, Nov 26, 2012 at 1:57 PM,
Bogdan-Andrei Iancu <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt
0pt 0pt 0.8ex; border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> <tt>Hi
Ali,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
</tt>
<div>
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a moz-do-not-send="true" href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre>
</div>
</div>
</blockquote>
<div>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. <br>
<br>
Something like this, assuming 1.10 is the first
long term support:<br>
1.10 - Long term support (2 years)<br>
1.11 - Standard release (1 year)<br>
1.12 - Standard release (1 year)<br>
1.13 - Standard release (1 year)<br>
1.14 - Long term support (2 years)<br>
<br>
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. </div>
</div>
</blockquote>
</div>
</div>
Hi Ryan,<br>
<br>
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.<br>
<br>
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).<br>
Do you know any project using something like that ?<br>
<br>
Thanks and regards,<br>
Bogdan<br>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>