Mailinglist Archive: opensuse-project (207 mails)

< Previous Next >
Re: [opensuse-project] Re: Code names
  • From: Mark V <mvyver@xxxxxxxxx>
  • Date: Thu, 7 May 2009 09:24:10 +1000
  • Message-id: <389c43e40905061624k2b95b95aod2f095ed2a83c956@xxxxxxxxxxxxxx>
On Thu, May 7, 2009 at 9:01 AM, Jim Henderson <hendersj@xxxxxxxxx> wrote:
On Thu, 07 May 2009 08:39:32 +1000, Mark V wrote:

Thanks for brining this to my attention. I had no idea that the EOL
date could change once the final release was made.

Now you're just being facetious. ;-)

No actually the first time I paid /any/ attention to what openSUSE does
with their lifetime/expiry dates was when I wrote that email that had
the lifetime wiki page linked to it. Up until now I've just adopted the
policy I shouldn't be more than 1 release behind the latest - I just
updated to 11.1 now that the 11.2 RC is out.

I can quite believe that a distro reserves the right to 'kill off' a
release if it proves too problematic to maintain - are there any
openSUSE guarantees on this point?

Sorry if I misread your intent, Mark.  :-)

I don't think there are any guarantees.

Maybe it will be clearer if I use a concrete example.

For the sake of discussion, let's say the current plan is that 11.0
reaches end of support on December 31, 2009, and that 11.1 reaches end of
support on December 31, 2010.

Also for the sake of discussion, the release dates for 11.1 and 11.2 are
December 31, 2009 and December 31, 2010, corresponding with the EOL dates
for 11.0 and 11.1.

The flow is thus that as 11.2 is released, 11.0 is placed at EOL.

With me so far?

Now for whatever reason, 11.2 isn't ready on December 31, 2010 and say,
for the sake of discussion, that it's going to be at least 3 months
before it releases.

If you EOL 11.0 on December 31, 2010 anyways, then you are not following
the stated goal to support "current release" and "previous release",
because at that point only 11.1 is in support (as the "current release").

If 11.0's been "codenamed" as "2010-12" because that's the EOL date, the
name loses its meaning when 11.2 slips and 11.0 stays in support for
another 3 months (assuming that it would for the sake of continuing to
support "previous release" per the stated policy of release support).

So then do you change the codename for 11.0 to align with it's new
anticipated EOL, or do you say "you know what, the codename doesn't
really mean anything" after spending the time and energy to decide that
it should mean something?  Or do you violate the support policy and
support only "current" release and not "previous release" because "next
release" slipped due to unforseen circumstances?

Or do you not slip 11.2 and release it even though it's not ready?

That's why I see using EOL dates as a codename for the releases as a bad
thing.  I hope that clarifies my thoughts on the matter enough. :-)

Yes it is possible to construct a release policy or development
shcedule where a EOL naming scheme is fragile.

Looking at the lifetime wiki page it seems OpenSUSE share your concern
and try to plan a release date while /two/ relases are alive.

Your point about the EOL date slipping as developments slips is valid
but can be accommodated:
- During development a planned release is coded named: <color>
- On the actual release date the release is named: openSUSE <EOL>

That last point was facetious ;)
I doubt you could name a release only on it's release date, URI names,
mirrors etc need to be set up...
But you probably could hold off 'naming' the release until the RC or
Beta phases, etc where the risk of slipping is possible smaller.



 Jim Henderson
 Please keep on-topic replies on the list so everyone benefits

To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups