2009/1/7 Gerald Pfeifer <gp@novell.com>:
On Tue, 6 Jan 2009, Rob OpenSuSE wrote:
Really I'm arguing for more minor releases, with smaller better focussed changes, done in a way that does get used, so that the FINAL retail release is of higher quality.
Would these minor releases be true releases, or more like milestones on the way to a true release? For example, once .2 has been released, will there still be security updates for .1 or will users be asked to move to .2?
I'd be ruthless, if you install .0, .1 then you *MUST* online update (or if absolutely necessary do a YaST upgrade to get to .2) if you want any form of support. Perhaps 12.0.0, 12.0.1, 12.0.2 would be more accurate, but these days marketing seems to prefer regular major version changes. Traditionally SuSE version numbers have been effectively meaningless. Having an annual major version bump, after the development phase of cycle, would keep openSUSE on a higher major version than Ubuntu however, which might be a useful side benefit. Having 3 or 4 minor version increments, every 8 months, and then upping the major version will fall behind the years eventually. ( I used SuSE 6.1 in '99, and am only at 11.1 in '08 now )
Perhaps it will be beneficial (for the sake of this discussion) to separate the question of naming from the contents, since numbers like x.1 or terms like Beta have certain connotations.
My feeling is that openSUSE Betas generally have not been more stable than Alphas, and RCs not necessarily more so than Betas. One way to combine this with what I _think_ you are proposing is to do, say, a mini-release (call it milestone or whatever) every 2, 3, or 4 months that brings a succint set of changes and has a _short_ stabilization phase, and then do a full release every three, four such mini-releases.
Only full releases will see security updates for 18-24 months, users of mini-releases will be asked to move to the next mini-release (which is still more stability than FACTORY provides today). Full launching happens for the full release, but we'll certainly want to also be a bit vocal about mini-releases.
Is this in line with what you are thinking, a sensible variation thereof, or quite something different?
You are right. It seems attempts to explain and discuss this seem to founder, because of pre-conceptions associated with the words. What you propose there, seems to be inline with ideas that I've tried to explore in the discussions. Incidentally I stumbled on this piece, http://derstandard.at/?id=3413801&_artikelIndex=1 which suggests it's an issue for other distro's to, even with an apparently larger user base. Shuttleworth discussing a rocky Ubuntu 8.04 LTS - "So we didn't see a sufficient level of beta-testing during the test-period and many bugs are only filed when the release has already been made. So one option that we considered was: "Let's not call 8.04 the LTS, let's call 8.04.1 the LTS", so many people would upgrade who wouldn't use a beta and you get better feedback. So that's something we might do differently with the next LTS. " Yesterday, I actually wished that when the 11.2 proposed schedule discussion was started, that I'd responded with something like. "11.2 should be released in March, it should contain KDE 4.2, and bug fixes to 11.1; basically it should be 11.1 done right. As it seems this is a common problem, it seems rather pointless to freeze the GM's with so many end users facing installation blocking problems (and if they do install, a whole load of known but unfixed regressions). And it was those involved most with the release, who originally aired points about shortage of testers and such. Other Novell employees have commented on lack of resources. That sounds very much like a reason to change, and a longer cycle was done with 10.3, and that still needed a huge number of updates post-release. So as it stands in Zonker's news item release plan, why would 11.2 in autumn be any different?
mini-release (call it milestone or whatever) every 2, 3, or 4 months that brings a succint set of changes and has a _short_ stabilization phase, and then do a full release every three, four such mini-releases.
That would appear to solve the problem of falling behind the curve of KDE, GNOME, Go-OO and the kernel, and any other noteworthy hotstuff & coolness. Assuming, that a goal at the end of the series is stabilised code for SLE, then you can limit the large internal developments to a merge window in Q1/Q2 in year say, with an increasing burden of 'proof' required as the Major release approaches in Q4. It would also permit, releasing with beta test versions, like KDE 4.2 for 11.1 (rather than 4.1.3 + backports), or as in the Shuttleworth example going with the clearly superior Firefox 3, rather than being lumbered with Firefox 2 for 2 years. My other main suggestion was to reward early adoption by online update, so that security patches only need developing for same number of kernels, OpenSSH and so forth as now. So in effect development goes on : Factory : the very latest in packages, no guarantees -- Debian "experimental" Current : bleeding edge, latest "mini-release" plus updates. Previous mini-releases updated live online if possible, or via an upgrade procedure with YaST booting from ISO. - Debian "unstable" Final Release : the stabilised product, that is fit for box sets, and paid support by easy migration to SLE Something like that, has a chance to build a community of beta testers, around an evolving release, which would actually run on real hardware. So to summarise : User Benefits : Less installing from scratch. A choice of stability, or current software. More involvement with the community distro. Fewer used versions (because of online updates) but better supported. Hope for higher quality in future eg) kernel driver regressions more likely to get back upstream in timely manner. Developer Benefits : Wider User Base, that grows with time as Full releases stabilise Getting usuable code out earlier, more time for real user Feedback Significant applications updates go onto a known base. Similarly core changes, can occur without having a load of unstable application changes as well. Fewer package versions to support (because "sick" versions, can be force upgraded) Less pressure to rush and opportunity to include "solid" beta's if it makes sense to online update later -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org