This thread and poll is to have a rough idea of what type of Release Cycle Model you prefer.
I voted Other…
I almost chose Rolling, however I don’t think it really needs 3 sub-categories. Keeping it simple, I’d prefer just Stable and Factory.
Realistically, the only time you need a new release altogether is when drastic changes have been made to the distro’s core. Beyond that, maybe each year re-package the DVD so you don’t have a huge download for updates.
The only reason I upgrade to newer versions is to ensure better support from repositories and build service.
I would love a rolling release cycle; however I doubt openSUSE has the manpower for such a conversion. The current release cycle is good, I just wish that we didn’t have be stuck behind several kernel releases before a new openSUSE release.
Rolling release would be great… Each install is such a stress : will my hardware be recognized ? Will the software be stable ? etc…
You actually want “current” I think and “Factory”. I suspect you want updates when new stuff comes out.
“stable” is more enterprise stuff where as little changes as possible, just security and other critical bug fixes.
Far too boring for the desktop, but … a great starting point for SLED/SLES I would think.
The current is theoretically each 6.6 months. And it seems to generate a series of releases in name only. They seem to be perpetually in bleeding edge mode, despite being declared “released” and IMO lurching from one not-quite-ready release to the next. So I chose annual to give more time to get a polished version on the servers.
I choose other, because I think 6 or theoretical 6.6 months are too short and with an annual release cycle the software/kernel versions a far behind the actual version. I would prefer a release cycle between 8-10 months so that there is enough time to get improvements into it as proven in the releases of opensuse 10.3 and 11.0.
I think the 8-month cycle (3 supported releases over every 2 years) works well. It doesn’t agree perfectly with Canonical’s wishes of synchronised distro releases, but nobody said that opinion was unanimous, and clearly few here have expressed a wish for shorter 6-monthly cycles. It also may not fit perfectly with the KDE / GNOME releases, but then they don’t tie in with each other anyway, so until they do, the focus should be taken off that.
The 8-month arrangement can always be slightly flexible, so one release may be 7 months to fit around a conference / other distro / marketing opportunity / Xmas / whatever, whilst the next may extend to 9 months to compensate.
Reading the comments on the mailing list and the prospect of aiming 11.2 for September’s SUSE event, but with a 11.2.1 GNOME update the following month, I would say if this occurs then there’s an equally valid case for doing an 11.1.1 KDE update when 4.2 arrives in February. Personally, as an ordinary desktop user and not a Linux expert, I found the situation with the factory repo optional update to KDE 4.1 in SUSE 11.0 rather confusing, and I’d have liked to have seen a more offical and clear update path, bearing in mind that the default KDE 4.0.4 was really a beta 4.1 desktop. I don’t imagine other less experienced Linux newcomers would have found it too easy either.
For the next two openSUSE releases, I think there’s a couple of specific, exceptional desktop environment cases to consider. The 11.2 release should ensure there is finally a watertight KDE 4.3 that can fully replace 3.5 and negate both the need for a 3.5 inclusion on the disc, and any last doubts that die-hard 3.x users may have. September sounds about right. In swinging that release in favour of KDE, the following 11.3 can swing the other way to cater for what will probably be the big GNOME 3.0, around April / May 2010. This plan can still fit in around the 8-month cycle.
One other thing to bear in mind that nobody’s mentioned yet: If openSUSE is seriously trying to sway Windows users away with an all-round desktop alternative, and with the Windows 7 release reportedly now coming before the end of 2009 rather than after it, SUSE should really have a finely polished product ready to compete and steal MS’s thunder; something that reviewers can hold up against it and which will still be cutting edge and not too far out of date by the end of next year. So releasing 11.2 before September and having nothing new till 2010 could be a bad move in that respect.
I also chose Other. I am torn between the 8 month release cycle and the rolling release. I hate having to re-install each release, but I do because I want the newer apps/kernels that are not included in the main repos for the previous release. A reinstall is the only way to ensure you get everything in the current release scheme. But… the 8 month release gives the project something to champion… like one of the previous commenters pointed out… Windows 7 is out in late 2009… and it would be great f 11.2 was able to steal a lot of that thunder, and fixed releases give us the possibility to do this
A lot of new users I work with will pick openSUSE (because I suggest it more than anything), and once it’s installed, they do not want to reinstall in 6 to 8 months. They aren’t interested… but with a rolling release, you could simply keep things up to date with YaST.
If it came down to it, in the end I think my preference is leaning towards the rolling release.
-1 for Rolling Release; +1 for 3 Releases in 2 Years.
Something needs changed, did a test install here on three computers, all had faults that for us are show stoppers. At this point we are restoring the 10.3 version to the test machines skipping 11.1.
Looking at bug reports none of these problems were unknown and yet the release was made anyway.
Had the same kind of problems with 10.0 and passed on it too.
Pretty sad commentary given that all of our machines are basic Dell systems, nothing fancy or weird in the mix.
What is worse I had several new users all set to start using the 11.1 version and at this point I can’t recommend it and don’t want to stick them with 10.3 and its older programs.
Although I like the idea of an annual release, I really like the flexibility our current system has. We can do a long development cycle if we want, but we can also do a quick 6-month follow-up release if needs be.
Rolling releases for the win. OpenSuSE should be rolling and SLED should be staged, taking the cream of the crop over time.
As OpenSuSE doesn’t have massive proprietary vendor support (compared to SLED and RHEL), there’s no loss of apps with the minor ABI breakage that occasionally occurs with rolling releases.
I find rolling release to be a very attractive alternative, but I cannot really foresee this as realistic for distros that has been versionbased for so many years.
1 year schedules will reduce OpenSuse relevance (no news no press no interest from potential new users).
6 months as used by Ubuntu is simply not sufficient - discrepancies are dragged on from version to version. Dissatisfaction with Ubuntu bughandling priorities and kernel modifications made me return to Suse after 18 months with Ubuntu.
My option is 8-9 months cycle which in my opinion would provide fewer showstoppers and still keep fairly well up to date in terms of Desktop Enviroments.
In terms of using KDE/Gnome to determine releases a 8-9 month cycle should balance this quite well. Having said that, the development of KDE 4.X has more momentum and I expect that to increase with 4.3. Therefore it might become more important to keep up with KDE. On the other hand, the factory/unstable versions of KDE 4.2 has been quite good and that makes it less pertinent to prioritise.
1 year schedules will reduce OpenSuse relevance (no news no press no interest from potential new users).
Good point. Same problem with the rolling release. If there are no major releases, then you sort fall under the radar. If releases are stretched out too far (like Debian), same result (only a bit worse; I tried to install Debian Etch on my machine, but neither my graphics card, wireless or wired networking devices are supported by the Etch kernel. I managed to get the machine running with it (by manually downloading various lenny or Ubuntu packages on another computer and manually installing them) then decided it wasn’t worth the trouble).
I’m for “other”:
-
A stable release every six months. Since KDE comes out in January / July and Gnome in March / September, I’d say split the difference and have openSUSE releases in April and October.
-
Two classes of packages, like Gentoo: “stable” and “testing”. “Stable” would be security and bug fixes to the previous stable release. “Testing” would be the latest versions of packages as soon as upstream called them stable by their standards and any openSUSE-specific changes were merged. I don’t see the point in Debian’s third “unstable” class.
On the issue of KDE vs. Gnome, if I had to pick today it would be Gnome, but give me time to come up to speed on KDE 4 and I’d probably switch, mostly because of KDevelop and Quanta+. But on laptops, I’d like to see better support for the lighter desktops: XFCE4, GNUStep WindowMaker, and Enlightenment.
One suggestion to improve the situation is a hybrid.
openSUSE releases annually a new version ie 12, in November, this is a “Final” which goes to boxset, and is supported for 2 years until 14 is out. Updates from (12-1) Final and to (12+1) Final should be better tested, and with useful release notes and workrounds for unfixable issues discovered during course of year.
Before that, around May after Autumn/Winter development, a 12.0 release gets pushed out to net early adopters, focussed on bringing updates to the core, bringing new kernel, and updates like glibc, gcc and YaST developments. It would only be supported until a newer release comes.
12.1, 12.2 come out July, September, October, as things like KDE and GNOME updates are being readied.
If you installed 12.0, online updating to track 12.1, 12.2 and then the “Final” as they come out.
With such a method, you should get wider testing on real hardware, with less instability and more focussed testing. There should be more “current” users, who can help test applications via an Online Build Service repositary of pre-release versions.
Also an interim release, permits the press coverage, as the latest big packages are available. The newer version, would naturally pick up more and more users, over Summer and Autumn, as it stabilises, and those ppl would benefit from not having to reinstall.
I chose 3 Releases in 2 Years. The reasons… pretty simple.
- The situation now is: a really nice release is pushed with nothing revolutionary.
Which is, generally speaking, a good idea.
Which is not, in fact, a good idea is that nothing really new has come up except new bugs. They take a lot of efforts to openSuSE developers and a lot of important hot-fixes are needed.
Why these efforts are not put in something different, something absolutely fresh and worthy re-installing the whole system once again.
I personally have encountered at least 6-7 major and very annoying bugs including network misconfiguration with 11.1 and as a result no Internet connection available. I’ve managed to manually configure it, but a newbie would simply not (I filed up the most part of the bugs in 11.1beta5, half of them - still present).
-
The operation system will still be in good shape and relatively up-to-date.
-
zak89’s opinion is absolutely…
“If releases are stretched out too far (like Debian)… but neither my graphics card, wireless or wired networking devices are supported by the Etch kernel.”… The Pure Truth.
I forgot to mention that according to me some important upgrades of the Video drivers (they are really under fast and evolutionary development, especially the ATI open-source RadeonHD driver) are totally necessary through the Build Service!
Those situations are where a hybrid model helps.
There are install disks, with latest install support, with a newer kernel. Having a choice of kernels, stable and latest hardware support, would help. Those with older hardware, could have a tried and true fall back for installation.
As it stands, bad experiences with a recent release, make ppl stay clear of Alpha, it’s easy to forget about Beta until RC is almost there, and then is too late.