Home Home > 2009 > 03 > 05 > 11.2 Roadmap and Fixed Release Cycle for openSUSE
Sign up | Login

11.2 Roadmap and Fixed Release Cycle for openSUSE

March 5th, 2009 by

The roadmap for 11.2 is now set, and openSUSE is getting a fixed release cycle!  Codenamed  “Fichte,” openSUSE 11.2 is planned for release in November, and releases thereafter will happen every eight months.

While all features for 11.2 are not yet settled, the release should include KDE 4.3, GNOME 2.28, Linux kernel 2.6.30 (or higher),  a Web-based YaST interface, netbook support (with free drivers), Ext4, and more.

The announcement was sent out today by Stephan Kulow on the openSUSE-Project mailing list:


As you may have noticed, we have yet to publish a roadmap for 11.2. The reason is simple: There are a lot of moving pieces at the moment, and we don’t want to commit to a schedule we can’t keep — or keep a schedule that doesn’t fit the project’s long-term needs.

To give us something to plan around, we would like to propose a fixed release schedule. As a six-month release schedule is not something we consider feasible to maintain high-quality standards, we are proposing a fixed eight-month schedule.
We have spent a considerable amount of time asking if we should go with a September release for 11.2 and then adopt an eight-month release schedule, or begin with an eight-month release schedule right away. And we came to the conclusion that it’s best to adopt the eight-month schedule right away.

A six-month release cycle is interesting because you “only” have to find two months in the year for a release. Eight months makes it slightly more complicated, as you have a rotating schedule, and lose a month in the summer and winter for holidays.

So, what we’re proposing is this — the next openSUSE release in November 2009, with the next releases in July 2010, March 2011, and so forth:

November 2009: “Fichte” 11.2
July 2010: “Rousseau” 11.3
March 2011: “Voltaire” 12.0
November 2011: “Lessing” 12.1

This gives us a single release in 2009 and 2010, and two releases in 2011. The version names and numbers may change, of course.

Public releases would happen on the Thursday before the 15th of the month, and the gold master (GM) would be finalized one week prior to that. We are planning a strict four-week release candidate (RC) phase.

This means that the last chance to change _anything_ but really urgent fixes would be the check-in deadline of RC1, which would be released in week 41 in 2009. The schedule would leave us with whatever software we have at that point. For example, we’ll miss KDE 4.5 for 11.3 or the spring version of GNOME for 12.0. If missing these releases is a problem, let’s discuss this _now_.

Of course, this doesn’t mean we can’t publish supported or unsupported addons or updated live CDs with the respective desktops or similar software: We just need people willing to do it.

Why such a late release date? Releasing 11.2 in November has some advantages over releasing in September:
- We don’t rely on contributions during the summer months that much.
- We can easily integrate GNOME 2.28.
- We are more likely to have working drivers for hardware released in early summer is higher. (This is a weak advantage since the summer release of Intel’s graphic chips didn’t work out with a December release either.)
- We simply have more time for everything.

The features we have in mind for 11.2 center around these top features:
* Newer and better software, including:
- KDE 4.3
- GNOME 2.28,
- Linux kernel 2.6.30 or higher
* Ext4 – possibly even as the default filesystem.
* Provide YaST Web interface for easier remote adminstration.
* Netbook support
- Offer USB images – possibly even with deployment tool if someone
writes it.
- Include free drivers necessary for the netbook support.
* Officially support live updates – we need way more people to use factory and report problems though.
* Quicker, Faster and more Colourful

OK, I better stop here. This is already a pretty long mail – looking forward to your feedback. The last time we discussed schedules, the feedback was very good – and got us thinking quite a long time. ;)

Greetings, Stephan

Both comments and pings are currently closed.

50 Responses to “11.2 Roadmap and Fixed Release Cycle for openSUSE”

  1. John

    Sounds great. I skipped 11 because 11.1 was coming so soon after it. I also think that, if you are planing a two year life for each release, maintaining two others is a better use of resources than maintaining three.

  2. lukaszSA

    Great! Can’t wait!

  3. I like the idea. The reason I use to install new version of OpenSUSE is to get rid of bugs. Unfortunately it happens that I end up with even more bugs. So I welcome the decision to prolong the cycle, hoping there will be more time spent on fixing them. If I need a new version of KDE, I take it from the factory.
    Thank you for your work.

  4. BenderBendingRodriguez

    While this is good news you can’t miss that there aren’t too many new features planned (at least for now) except a natural evolution like next DE release or new kernel. The schedule is not as interesting as let’s say upcoming features list in 11.2

  5. 6205

    Sounds good, no need to rush things. Looking on that KDE 4.3 – v11.2 smells like Windows 7 killer :)

  6. Cypher

    I personally do not think that missing KDE 4.5 is a good idea, especially if it proves to be as stable as KDE 3.5. There are huge differences between KDE releases, while GNOME releases only bring little improvement. We made the choice of openSUSE + KDE4 for our business, all our employees use it as their primary desktop, so I cannot afford using Factory. And we need the KDE improvements because they make our workers’ job easier. So please consider supporting every KDE4 release. openSUSE is the only distribution that ships a suitable quality level for business (not taking the distributions involving support), we rely on you.

  7. Bob I

    An 8 month cycle! 8 months! This is great short enough to stay new & long enough to get it right! With all the MSFT imports we’re going to be getting soon 8 month cycle is ideal, especially for them.

  8. Buschmann

    Congratulations for the codenames. Really great idea to use names of famous philosophers. I am now awaiting openSUSE 12.2 “Kant”. ;-)

    • Frank

      So You ‘Kant’ wait? … I too like the idea of using famous philosophers. I wonder if there were any other criteria for choosing the particular names … why begin with Fichte for instance?

  9. Markus

    Gosh, what’s with the obsession to make ext4 the default across various distros? XFS has always been better than ext.

  10. Justin

    If this helps you keep half-working software out of openSUSE, then go for it. I’m tired of “upgrading” and having things break, when they used to work out of the box. I’m running 11.0 now, because 11.1 doesn’t work. I’m so tired of it, that I’m going on a search for a different distro. However, I still really like openSUSE and hope that, come November, I will love it once again.

  11. i think it’s too long to released.first, i hope 11.2 would released in september or october.
    But as opensuse fans, i’ll wait…
    when i look top features in 11.2, i think it’s worth to wait that long :)

  12. Michael

    why not a 12 month cycle?

    would be easier to align with gnome/kde, and once a year nowadays seems often enough; the Ubuntu/Fedora approach leads more often than not to less than perfect releases; I certainly would prefer a rock solid release once a year

    (for all who think this is too long: from 11.1 to the projected 11.2 release it takes 11 months; and almost nobody is complaining …)

    • Agus Winata

      great news…

      i agree with you Michael.
      how about rolling release?? i think its good idea :-)

    • isegrim

      I agree. One release every 12 months would be good. Rolling Releases would be *that* great.

  13. Dimble

    Sound great, except that its an awfully long time to wait for a fully integrated KDE4 system.
    On the other hand it should ensure inclusion of a stabilised 2.6.31 kernel and X.org 7.5.

    I am fine with the 8 month release, but i would dearly have loved to see 11.2 release in september.

    • Dimble

      On the other hand, i plan to buy a new computer in summer when the new AMD 8xx series chipsets arrive, so it is nice to have 11.2 with a kernel that will hopefully have support for the chipset i intend to buy.

  14. Luke Szabo

    I would much prefer a normalized, rather then inconsistent release schedule of 8 months, this means that some years there will be 2 releases and others just one and it will not be a consistent month either, so it will be difficult to plan around other peoples schedules, and especially for business purposes to plan around standard company software freezes that would prevent deployment of an updated OS due to internal time frames.

    Would it not be better to, after the November release, to release on a yearly basis after this, November being a very good month as it is close enough to Christmas to be sort of a gift to your supporters and long enough away from Christmas that people will have time to upgrade and get comfortable with new features before the Christmas break. It would also allow companies enough time to have their teams create standard images/installs and do some testing over the Christmas period, as most companies like mine, have freeze periods over this time that would allow the technology teams to do any testing in Lab environments during this time to have a stable and tested platform ready to go when everyone gets back from their break.

    I think yearly would be a good option, as long as there is a provision there for people like myself that thrive on having the latest and greatest with no concern for stability, in that I am happy to help test the stability of platforms on my system, as I always have one machine with a stable release.

    • steveedmonds

      I agree with a yearly cycle. We use our SUSE in business and a fixed cycle helps us plan hardware, November is a good month in the southern hemisphere too.

      What would be good is an extended support release, may be 11.2 or 11.3 with 5 years or minimum 3 years to work around hardware upgrades. Updating SUSE has never been easy (it’s never been stick a disk in, click update, and its done), in fact I have found I rarely ever update until I update hardware because updating is too time consuming for a business, resolving non distribution package updates and dependancies.

  15. Will

    I am not very familiar with Ext4. Will it provide the ability to do full disk encryption from the root? One of the requirements in many institutions these days is to be able to provide full disk encryption on laptops. This can be a show stopper for those that are trying to promote a Linux alternative as many third party encryption products are almost solely Windows based. If they do support Linux, it is often only an older version of RedHat. I know there are complex workarounds, but could you please consider working an off the installer solution to open the window for this corporate compliance? The directive is that the full drive needs to be encrypted. If you can’t provide that… then install Windows.

    That would not be my first choice. Please give me another option so I can keep my opensuse.
    Thanks.

    • Chris

      EXT4 works perfectly fine on an encrypted partition (also the encryption should be transparent to the filesystem so its type shouldn’t matter anyways).

      The problem is that currently the openSUSE installer doesn’t support installation into a fully encrypted root (obviously with the exception of /boot). The feature request for this is https://features.opensuse.org/305633

      Vote for it and advertise it to people so they vote for it as well so it gets done for 11.2 (since all the necessary stuff is already in place all it should need is some change to the installation script … but someone has to do it ;D)

      • Will

        I would love to vote. How do you do that? Do you register at this link and attempt to add a comment? I know a slew of people that would really benefit by this feature. The cost of data loss to an organization can easily vault into the millions for some organizations. That is why it becomes mandatory to have full disk encryption policies. This is a deal breaker for OpenSUSE and will ban it from our higher education organization. That translates to banning it from the campuses as well, all due to what the article appears to describe as a fairly simple solution. You would think that would make it a priority. What students get used to tends to travel with them when they graduate to the real world. Must that be Ubuntu? Have I convinced the team yet? Do they realize this “small” detail has significant repercussions? This is real. I am on the IT staff and work with the decision makers for an institution that has tens of thousands of students. The economic hardships are opening the door to consider other possibilities. I would love it if OpenSUSE could be part of that.
        Thanks for listening. If you have influence please pass this on.

        • Chris

          Simply login with the credentials you use for Bugzilla / Wiki / Forum / OBS and then press on the up arrow in the upper right corner (where it shows the score).

          Also get your collegues & other interested folks to create an account & to vote for this ;D

  16. cast_iron

    I would love to have yearly releases as well, but with a half year mini upgrade (read: service pack) where the latest version of x.org and the DE would be upgraded without having to use factory repo. It seems to me that doing it this way would provide good stability and predictability while not losing out on the latest X and DE (which is important to many home users, I would think). Anyway, what do you guys think?

  17. @cast_iron: that sounds really sensible imo.. really hope this is going to happen :-)

    stable because of longer development lifecycles + getting updates in the middle of it sounds like a nice solution to me

  18. VintagePC

    I agree with Cast_iron-a ‘service pack’ type idea. (or at least offer a service pack repo where people can get the latest major updates to the software in the distro (e.g. OO.o 3.1, FireFox 3.1… etc.) This way, we don’t miss out on major releases of components just after the release date, and one can avoid the ‘factory’ repo’s ‘issues’ where you might need to add a new component or re-install, but since the repo has updated, you need to upgrade all your packages from that repo to keep versions matching.)

  19. spirov92

    Service pack? Great idea! I would love to have the latest release of KDE4 without having to reinstall. It would probably be best as a repo.

  20. Anonymous

    “Quicker and Faster” is really necessary.

  21. Luc Levain

    I think the 8-month period makes a lot of sense for corporate users, and is quite in tune with the image of openSUSE as a solid, stable distro. Business users would typically value stability the most and the can wait until the latest bling in technology is fully tested and integrated.

    However, I think it comes with a cost to desktop users. Especially the more advanced ones, who read about and get excited by the advances brought about by new releases of different parts of the Linux ecosytes, would probably like to be able to use them as soon as possible. (And even for the newbies these may make a difference if they bring improvements in performance and usability.) As an example, when kernel 2.6.28 hit the shelves in December, it made quite a buzz with the integration of ext4, the GEM graphics manager, the promised performance imporvements, etc., etc.; similarly, the winter release of KDE 4.2 brought very positive reviews. Now, for these kind of users, a November release means that they have to wait almost a year to see ext4 integrated, unless they want to compile the kernel on their own; and they need to use KDE4:Factory to profit from all the KDE improvements.

    I did not think that was a problem (if a more advanced user wants new feature, they can do the extra steps required to get it), until X an update from the openSUSE 11.1 X11:Xorg repo started to hang my system last week, and, while searching for the solution, I came across an openSUSE mailing list post (can’t really find it now, sadly) saying that the repo is not meant for endusers. (Note that this was not a Factory, but a 11.1 OBS repo.)

    So, my problem and question is that: how can we assure that the enthusiasts who want the latest and greatest technologies can get them in a not-too-complicated a relatively stable way, without having to wait 8 months until the changes are integrated into the next release? With all the buzz happening around new distro releases and all the improvements they bring, having to wait so long might be enough to at least consider jumping distros. So, would it be absolutely not possible to, say, provide a 2.6.28 (and consecutive) kernels – or imporvements like speedboot, readahead, Plymouth etc. – in a way that’s easier than compiling from source and slightly more supported and integrated than personal repos of users (although, obviously, without the stability guarantee that a full distro release brings)?

    Personally, I think that the layout of the KDE4 repos makes a lot of sense. If I want the very bleeding edge, I use USNTABLE/openSUSE_11.1 or even UNSTABLE/openSUSE_Factory, and I can expect things to break, as that, I gather, is where most of the development and testing takes place. If I just want a newer release, I have Factory/openSUSE_11.1. Sure, I give up some of the promise of stability, but I know and can expect that things will mostly (and, from experience, that’s 99% percent of the time) work.

    As there is a lot of exciting progress in the various components happening, and more and more buzz around them and interest in them, catering for new releases of major system components (the kernel, X, desktop environments, office software etc.) is increasingly important. Otherwise, I think, there is a risk that some users will say “hey, that other distro XYZ gives me these right now, or in a month’s time, and quite stable too, so why stick with obsolete technology?” And losing users is never a good thing.

    Anyway, that’s just my two cents.

  22. Simon Lewis

    In principle I find the 8 month cycle good – the impression from the 11.1 release was that it was rushed and the release candidate was not really tested.

    However, many notebook users will be disappointed with the long wait for an actual kernel with the latest drivers.

    I would welcome a remastered openSUSE 11.1 with the 2.6.28 kernel (and perhaps ext4 and KDE 4.2.1). This would be really good as interim solution…

  23. Minton

    I suppose there will be no remastered 11.1 cause all developers are busy with SLE 11 products. And after the SLE release it will be just right time to start hard working on 11.2 – so be realistic =)

    • Simon

      Hello Minton

      Given that other stable distributions like Ubuntu have already or will be launching in April final releases with the current kernel and desktops, is it realistic for openSUSE users to wait a further 8 months for the same features? Or can the 2.6.28 kernel and KDE desktop be backported to the standard openSUSE 11.1 repositories?

      Simon

      • Chris

        Yes, imho it’s realistic for openSUSE users to wait a further 8 months to get new versions … If that is good or bad might be argueable but it definitely makes it easier to support.

        If you are in desperate need of newer x.y.z+1 versions then go and get them, unsupportedly, from the Build Service (KDE & KOTD) or from jengelh’s repo.

        If this isn’t acceptable for you, then you are using the wrong distro since (as rude as this might sound).

        OTOH, switching to a rolling release cycle sounds appealing ;D

  24. Mike

    I think new releases of openSUSE should coincide a month after KDE releases, just as new releases of Ubuntu coincide a month after GNOME releases. Ideally, when a new version of KDE is released, the first distro people should think of is openSUSE.

    Currently, when I see discussions regarding a new version of KDE4, someone will usually ask which distro to use to evaluate the new KDE4 version, but there is never popular answer. Whereas, when I see discussions regarding a new version of GNOME and someone asks which distro to use to evaluate the new GNOME version, the popular answer is always Ubuntu because new releases of Ubuntu coincide with GNOME releases.

    Stephan Kulow wrote:
    > we’ll miss KDE 4.5 for 11.3

    openSUSE is famous for the solid KDE experience that it provides. Everyone I know who uses openSUSE does so because its KDE support. Adopting a release schedule that will result in missing KDE 4.5 doesn’t make sense to me. But I’m not an openSUSE developer, only a user, so my understanding of the situation is limited.

  25. Vincent Liu

    Constant release cycle is a good idea, but I oppose this plan. The reason is that predictability will push people to release unfinished works. There are always unforeseeable events that could not be predicted in 8 months or 1 year. Distro like Fedora and Ubuntu should be more stable to call a release. When I was a user of them, they always broke sth within 2 days after install. I prefer waiting for a ready openSUSE rather than a predictable one.

    I don’t know other factors that affect this decision, but if the release time is crucial, I agree with 1 year interval and the proposal of cast_iron.

  26. kwins

    @ Simon Lewis :In principle I find the 8 month cycle good.

    That’s true so we can search for buges and look the best for suse and so we can make this distro the best.

    so let we for 8 month cycle.

    cheerz ;)

  27. PeterPac

    After reading the comments everyone should realize that openSUSE development cannot please every user, all the time, or they would be creating 5 or 6 different versions. Bleeding edge, continuous updates, new kernel releases, open office and browser updates, etc. Yes, while other distros have different schedules we also must remember openSUSE contains a lot more programs than the others, is easier to add programs to. Business are more concerned with stability than bleeding edge newest programs, while others want the newest and latest programs. We must remember some of the major programs are maintained outside of our development and their schedules are not the same as ours. Instead of waiting for the 8 month cycle a interim program update for a major component could occur if the program is proven to be stable but than that also takes in whether there is any dependency problems. I have to agree if we release according to schedule and 1 month later a major component is upgraded or updated waiting another 6 or 7 months to have this updated would be a little far fetched.

  28. nitroushhh

    I don’t think we’re really having to move from 6 months to 8. The 11.0 to 11.1 was 6 months but the previous ones were 8, 10, 7, 7, and then a 6 in 2005. Thats why we think 11.1 turned up quickly. :-)

    I could imagine a longer release cycle meaning some wasted work. eg. testing and feedback on a version of something that gets replaced during the cycle. But I expect this would always be the case, just more significant on a longer release.

    If we were to have a longer release say 8-12 months, I’d like to see more effort for helping us run more up to date packages and ease high quality bug submission. (if thats what the project could find useful.)

    Just some ideas off the top of my head…….

    Perhaps during install we could have an option of making an extra factory partition. Not by default. Hard drives are soooo big these days I’d have no problem with having a 15gig factory partition. Perhaps some notes to read on what it means and how to submit a high quality bug. A wizard even that takes you to the site to help you find if the bug’s already submitted. Then I could run factory on a daily basis and if it breaks i could boot up the stable release. Maybe replace that with the betas as they appear or help us have stable, factory and beta/rc partitions. They would only be extra options on the grub menu. Some nice delta updates to move from beta to beta (with bittorrent maybe). And perhaps even something to keep the same packages in all our partitions. I think a lot of us wait for release candidates or GM before trying and then find something is broken for us. I missed a release because the chipset on my laptop got a bad driver and i couldn’t fix it even with a lot of effort.

    We might even subscribe on install to notifications of new suse kernels. When a kernel is picked for an upcoming release we could have it in our grub menu, boot it up and check what hardware worked or didn’t. Maybe auto, maybe with our feedback. Perhaps other notifications, like callouts to test certain hardware or software. Perhaps even the mainline kernel betas, hardware auto tested by us. Or on request if we have certain hardware someones interested in.

    It would encourage more of us to test more stuff, keep us up to date during the longer cycle and hopefully improve the quality of our feedback.

    It could all start with a checkbox on install “I want to help. X”. Or “I want a cutting edge partition as well X”.

    All with 1 home partition, remembering to have a different userid for each partition.

    But we don’t want to overwelm the project with poor feedback. So would need a lot of thought.

    Well just some thoughts.

    Help me help you. :-)

  29. Simon

    @Chris: OTOH, switching to a rolling release cycle sounds appealing ;D

    Perhaps openSUSE should be innovative and develop a totally new distribution concept…

    For example, new stable versions are automatically put into the current stable repo and the downnloadable DVD/CD is a snapshot of the current stable version…

  30. nitroushhh

    Getting better feedback and getting more people involved in testing would be far easier if it wasn’t so darned difficult to submit bug reports. One gets taken from the OpenSUSE site to a Novell site which requires a user account, etc, etc. There doesn’t appear to be any simple documentation on the process and once one gets to the Novell site it really appears like you’re signing up for a paid support service just for the right to submit a bug report. Barring that, if the OpenSUSE project wants some good feedback try scanning thru the forums and see where people are having the most difficulty. Networking, device drivers, incompatible packages, incomplete or incorrect documentation, performance ….

  31. nitroushhh

    I didn’t make that last comment ??? how did that happen ? :-)

  32. munir

    I think 1 year release cycle with a service pack 6 month after the release is the best

  33. Mark

    I would like to see an extended support cycle. CentOS is five years! Two years is too short. Having finite resources, if a one year update cycle would allow an extended support cycle, I would be in favor of that.

    I would also be in favor of a six month service pack, if I could still use “yast” or “you” to maintain the security patches. If I can’t easily maintain the security updates, I tend to fall behind in applying them. Remember, “KISS”, Keep It Simple S…

  34. toby

    11 months from the last release is awfully long. Sep or Oct would have been nice. 8 month release cycle is good, but it should have been applied to the current cycle, too. I only hope that 11.2 still includes KDE 3.5 in addition to 4.x. I don’t need all the gimmicks.

  35. My Bum is itchy………

  36. Only if you use a ShoeHorn ;) LOL!

  37. sid

    Great plan, great decision !

    As for me, it could be even once a year new version, just to make thorough testing and release really stable, because for me, 11.0 or 11.1 were not so much stable just after install, without doing some tricks.

    So, I really like this change and I hope it will make positive consequences.

    Regards !

  38. steveedmonds

    Just looked at updating my HP laptop again.Its running 10.2 – KDE 3.5, now unsupported.

    I tried 10.3 when that came out but that was no good. 11.0 KDE 4, no good. SLED – too restrictive.
    I tried 11.1 KDE 4 live CD, its getting there but usability for my installation choices regresses. I think 11.0 or 11.1 with KDE 3.5 would have not been a regression but really I should try to move to KDE 4 as the life of 3.5 is up in the air.

    So may be by November 11.2 with KDE4 will be able to replace my 10.2.

    The discussion is on life cycle, I use SUSE in business on a number of machines and wish to continue so. It does not need to be leading edge but I would expect (for business and to attract corporate confidence) that I could update without regression and that I would have support (at least security maintenance) between updates. I can fart about a bit on my PC but I can’t spend time tinkering with every other users PC too often or when upgrades don’t move forward.

    Hence this leads to my argument that there should be “locked in” releases with longer support, support that carries the locked in release to the next release that does not regress. In my laptops case support of 10.2 to say 11.2 (having tried 11.1 and read about the improvements on that for 11.2 I am confident this will be able to replace my 10.2).
    10.2 would then be “locked in” until 2+ years down the line a version is released without regression.

    This locking in is for the benefit of users who chase reliability and dependability rather than leading edge. Which version to lock in only needs to be made before support is dropped for that version. I found, and so did many others, that 10.2 – KDE 3.5 caused less hassles than 10.3 and generally 11 – KDE4, so it may not be necessary to nominate a release for long term support until 2 releases after that release, when its realized that the current release is not corporate ready.

    Cheers

  39. It sounds great. Many days and night to see it, for sure it will be a great version.