On Thu, May 7, 2009 at 9:01 AM, Jim Henderson <hendersj@gmail.com> 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. Cheers
Jim
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org