openSUSE 11.2 release schedule

Michael Loeffler just posted a proposal of the release schedule for openSUSE 11.2. After going through some of the discussion threads I came to a couple off conclusions:

1. I love to have the newest apps, desktops, features, but… at what price? It’s always a question off stability and maturity. One for example will go for ‘the hills’ with beta’s, RC’s and all unstable versions he can get just to have ‘newest’ and ‘greatest’ and ‘most feature-packed’… the other would be willing to wait a bit just to get those tested, documented and polished to the highest level.

I’ve been there with openSUSE 11.1 from beta4 and belive me, there were countless times I wanted to go back to 11.0 lacking the stability, support and so on.

Ask yourself why do we wait for the final release? Because it’s going to be STABLE, DOCUMENTED and OFFICIALLY SUPPORTED. And remeber that maturing with time isn’t only connected to distros as a whole, but to every single apps or feature itself.

Why do we have to go for ‘bleeding edge’ with day to day implementations of GNOME or KDE, when we can use the latest, stable and managed versions, witch have been there for a month, or two.

2. GNOME, KDE, OpenOffice releases should be linked as for release date… but what for? Why should the guys at KDE work according to Sun’s OO release schedule? What happens when we put the deadlines for the releases together and try to manage them? Chaos! Instead of polished versions You would get 'running blind to keep up with the date" beta’s.

Remember that distros are build based on apps and desktop environments (multiple distros use the same software). OpenOffice for example isn’t dedicated for any of them (if it was, wouldn’t it remind You of some Redmond company’s policy… I’d get a dejavu for sure;)). So we can’t expect from soft developers to keep up with a single distro’s (every single one) schedule… the only way for this to work is the other way around.

3. Don’t try to set up any release cycles… why put yourself within boundries, close within limits… why gave up the flexibility, the freedom… don’t worry about us (the users). Most of us are not kids, who need a new toy for every Holiday;) We can wait, because we know, that post-development, bug fixing and polishing has to cost time.

Distros, that stay for longer, receive larger doses of support (HOWTO’s, hints, tutorials, docs, specs), mature hence become more usable for a newbie. The bigger the support, the bigger the community… is it not;)

So guys…take Your time in developing SUSE for us…there is no rush…


You can find this post on my blog site (please check out;))

That URL is no good. I think you meant:
[opensuse-project] openSUSE 11.2 schedule](

My mistake…sorry;)

I agree, it’s better to have a stable distro than crap i would be cursing at every 5 minutes (KDE 4.0 anyone rotfl!??) and if someone wants to live on the bleeding edge then that person always has backports, factory and unstable repositories right?

But we need those at the bleeding edge. As long as they make bug reports, etc. that is. Because those who want a stable release only will get it after thourough testing in ‘the wild’.

I take the opportunity to thank those that wrestled and got fustrated by using the alpha, beta, rc, you name it, releases to the benefit of all. Particularly for the benefit of those that are sitting lazy in their chairs looking at all those threads and bug reports coming by, knowing they will at the end get a very stable and satisfying piece of software.

Of course i agree but using backports or factory or other bleeding edge repos isn’t stoping You from filing bugs or is it?

I hope not.

Guys guys…sure that ‘bleeding edge’ releases are necessary, but…distro’s final release is not the place and time.
I myself like testing new software (openSUSE RC1 for example), but when I (and a huge amount of other users) receive a package called GM or ‘final’ I’m counting on finding polished, working, non-buggy software inside. After that I can always enable ‘factory’ or ‘unstable’ repos and have all the ‘bleeding edge’ I want.

Well it’s already been told :slight_smile: But i agree again;)

I agree with the proper documentation and also procedure something like what LFS (Linux from scratch) documentation . I following Opensuse 11.1 from alpha till rc1 , if you ask me whether the final will be good or bad , the answer will be “MAYBE depend on luck” .

you can see your self the quality in the developement . some bug that not suppose to happen (that will make you look stupid if it happen or human error) it happen . some bug fixed in this version come out in next version .

if such problem happen on 1 or 2 stage still consider accepted level but it happen until RC1 . the whole purpose of dividing the stages become useless.

there really need for revise in the procedure and divide each part/section , so that easy to control and tracking bugs and prevent human error .

Opensuse and linux it self have grown very big and complicate . need to layout proper map and work order in order to move for better and stability .

Well… it does not have to be on or the other.

If you setup you disk partitions so you can dual boot between your cutting edge and stable release you get both.

One thing here with the beta’s… always make an image of your root partition before engaging in major updates. That should save you much pain if something goes wrong with repo’s, versions, etc… And as always, regularly make a backup of your working DATA for that occasion that all goes belly up.

I normally have a boot manager on my own systems… also to be able to make and restore images right from boot. With that I can revert & be up and running within ten minutes.

With the first Beta’s you’ll be glad to be able to boot in the previous working version… and as the release date gets closer there is often a turning point at the last beta where I switch over to the latest and greatest.

Just my 2cents,


I agree with the OP that the final distro does not have to be bleeding edge. Also software shouldn’t have to follow a distro release cycle, although in some cases this already happens.

However, I disagree with the idea that there should be no release cycle for the distro at all. Yes the final software should be as stable as reasonably possible, but there’s something to be said about release schedules you can depend on.

Personally, I also like time management stability - I like to know that I can plan a weekend well in advance to upgrade the PCs with the newest openSUSE/Ubuntu/distroX. That in itself has some value.

You do need schedules to plan the work properly. The OpenSUSE are not a bunch of enthusiasts building the distro in their spare time. They are a team of highly skilled professionals and are paid salaries. As always the risk of introducing some breakage is there, and one can only trust in their judgement when it comes to decisions to introduce a new package or to leave it for later and retain a stable but older package. Mistakes will be made sometimes, that’s life. But progress must be made too. That’s why versions vary in acclaim.

On your part, nobody is forcing you to upgrade. If you are happy with what you have, there will be over another year of life for it. Just wait for the brave bleeding edge tasters to tell you about the problems. After all, it does take effort and time to do a software upgrade, although it gets easier and easier.

No hard feelings on the professionalism;)

It’s just a question off wheter the user is willing to wait a couple of weeks more, if he desires to get a polished product, or a ‘must have’ with a feeling, that something’s missing (anybody tried Vista…hands up;))

I’m just saying, let’s bring up a plan, but an open one…not to open, but still reschedules are always a part of such a big project (take my masters thesis on Networks on Chip implementation…constatly rescheduling for half a year;))

release schedules have a reason, one it gives people something to aim for, and they have aimed for it rather well, reading up on the internal rc, it appears they have a **** good release ready to go. Other reasons are you can’t build a product and just walk into the businesses and demand that they produce your DVD’s for you. You have to have a schdule to book companies who are going to be doing your work and to let those who are going to sell it know around when they can start selling your product.

Personally, I have never been let down by an OpenSuse release yet.

At 9 months that gives plenty of time to get it right, from the start. For the newbs it’ll be easier for them if they don’t have to mess with too much at the start. I wonder how many out there think Opensuse is a crock because they installed 11.0 with KDE4 & because they came here from Windows didn’t understand how to put in KDE3.5?
IIRC this time an effort is being made to have all the latest, stable stuff. We need to have these in proper working order for the newbies,especially the Windows imports that’s where a good chunk our growth is.

to make it short , Opensuse need a Quality control management systems. what this system should do is able to let beta tester to record down they testing in detail.

for example

  1. for hardware control
    every beta tester will need to register detail of they machine . if some of the hardware not working, user can update the find out also the solution . other beta tester also able to search this database for solution . if the alt solution also work then they will also need to update the info into database.

this way when moving to next version the developer know (from searching into the database) which hardware working which is not also which driver is working which is not .

I know it’s hassle but it will improve quality from one version to another .

the forum function is not good enough since we don’t know who actually no problem also why no problem occur.

I hope such quality control system will be implement.

Release cycles remind me of EA games, like FIFA…yearly (November i think) the same stuff, almost nothing new, maybe one or two bug fixes. On the other hand we have Pro Evolution Soccer…not yearly, but every time (well almost) something new, evolution…

Schedules are a must, because, as You said, this is business, but…let’s consider that during the development process there are things You can’t predict. Solving problems some times takes a day, some times a week. Often when the distro comes out, there are still some bugs left, some issues to attend to. If the developer has a release cycle ‘on his head’ instead of focusing on fixing, what’s left, he is instantly ‘thrown’ on to a couple of new fields. And what about the issues, that he lefts behind?

I think that with so many packages it will be impossible to say, let’s wait for this to get fixed. Ok so you wait for that, and then something else is improved during the same time, and then do you include that latest version? It never ends.

Rather, its more likely that contingencies will be dealt with by saying, if this package isn’t good enough, we’ll ship an older version for this and not go with the latest release. It’s all part of the planning process, the developers have to make as good a guess as they can about what they are likely to be able to fit in.

Mid August release, get KDE 4.3 in there.

if the plan is to drop KDE 3.5 then KDE 4.3 should be a requirement to get within spitting distance on feature parity.