Home_greyopenFATE - openSUSE feature tracking > #310122
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Extend Support Period/Revise Release Cycle

Feature state

Rejected Information



1. Conservative users get their "super-stable" release in the respin, which will include all the official bug fixes from GNOME/KDE/Mozilla along with the squashing of most major bugs that may have cropped up in wider testing.

2. People who have bandwidth limitations would benefit from a 'maximum fixes included' iso being available.

3. Gives openSUSE consistent release months that everyone knows and can plan around, rather than the current tumbling system.

4. Provides the artists, programmers, testers and translators a longer period of time to work on things for each major release.

5. Aligns our current version number scheme with what it implies: Major and minor releases.

6. Prolongs the shelf life of all support mechanisms. Forum helpers don't need to shift their support target as quickly, manuals and wiki pages stay valid for longer periods of time.

This also means openSUSE books have a longer viability period in stores. If an openSUSE Foundation is created, perhaps we can negotiate some sort of revenue-sharing deal which will help support the foundation.

7. Given the support commitment of "two releases plus two months" the support cycle would expand from 18 months to 26 months - the respin doesn't count as a proper release since it just a collection of bug fixes for the major release.

8. Reduces the feeling of being on an "upgrade treadmill".

9. Provides us with something that makes openSUSE distinct from other distros - a good period of support for every major release.


1. There's supposedly a large segment of Linux users that want new software, but are only willing to get it through brand-new releases of the whole distro. I think this segment is misunderstood. The users who need major releases to get new software are doing so to get around their frustrations - new software is not being provided via online updates.

The presence of the OBS means anyone who really wants the newest Amarok/Chromium/OOo/whatever can get it - what we need to do is make the appropriate OBS repos more discoverable.

2. openSUSE will miss a major update to GNOME/KDE. I don't think this is that big a deal. The current 8-month release cycle already misses major versions (for example OS 11.3 will have KDE 4.4.x while OS 11.4 will have KDE 4.6.x).

User benefit:

Move to an annual major release with an additional bug-fix remaster.

An Example of How it Would Work:

Every June* a new major release of openSUSE is released.  All the components get their usual refresh - kernel, DEs, OOo, Mozilla, etcetera. New features at the distro-level also get implemented, the sort of things that are ususally requested here on FATE or in bugzilla. This release would be like every other release of openSUSE so far.

Then in November*, a bug-fix respin would be published (aka a "service pack").  This would be the major release plus all the updates released so far through the standard update repo.  Given the new update policy this would likely include upstream bug-fixes from GNOME/KDE/Mozilla plus the usual assortment of openSUSE security fixes.

Version Numbers: Our next (major) release would be 12.0.  The bug-fix respin would be 12.1.  If there is a second bug-fix respin it would be 12.2 and so on.

[*A different month might be considered more optimal by the community]


icons/user_comment.png T. Z. wrote: (8 years ago)

I think this would be shit, since 8 months is allready a very long release cycle. Also OBS is only a solution if a couple of Packages are to old, not if you want to update your entire Desktop(KDE + Office + new Kernel for drivers etc.). Because of these reasons I think openSUSE should stick to the  8 month release cycle.

icons/user_comment.png R. S. wrote: (8 years ago)

The most popular OBS repos include those for GNOME and KDE...Both of which are considerably more involved than "a couple of packages".

Furthermore, consider the fact that openSUSE 11.3 is already outdated, shipping with 'old' KDE, XFCE, Thunderbird, KOffice, Midnight Commander and more...and it isn't even released yet.

If one needs the newest everything from kernel to desktop widgets, then why not use a distro designed to provide such a service in the first place? The best solution to the "latest & greatest whenever I want it" problem is using a rolling-release distro.

icons/user_comment.png T. Z. wrote: (8 years ago)

OpenSUSE is perfekt for me, I've got the KDE4:Unstable Repo enabled and it works just the way I want it(I want a relativly new Distro not bleeding edge, for stability reasons), so I hope openSUSE sticks to the current release cycle or I gotta switch to an other Distro which would be a shame since I love all the openSUSE tools like zypper and yast.

icons/user_comment.png S. S. wrote: (8 years ago)

There is sled for those that want a more stable release

icons/user_comment.png R. S. wrote: (8 years ago)

Although I am not dogmatic about changing the release cycle, I would not consider SLED to be a solution for the average user. Since Novell requires one to purchase a support contract to receive security fixes after a short trial period, SLED over time is effectively less secure.  This same flaw also makes it less stable/not feasible on newer hardware as time moves on (Service Packs notwithstanding).  Sure the user could buy the support contract, but they could also just download CentOS or an Ubuntu LTS release.

icons/user_comment.png O. R. wrote: (8 years ago)

Increasing openSUSE support period would be perfect. 18 months is way too short period for any operating system that should get things done. Previous 24 month period was differentiating factor, with current 18 months openSUSE became essentially "yet anothing test-bed for commercial distributions".

openSUSE has zypper and OBS to meet demands for more technically oriented users. Mentioning zypper, because unlike with apt in Debian, I have never had problems downgrading packages with it. This makes long support period for base system with up-to-date secondary repositories very tempting idea, as technical users can run bleeding edge software on top of the system while having quite safe fallback route in case something happens.

Last change: 7 years ago
Loading tags...
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint