Feature changed by: Refilwe Seete (ReferenceSeete) Feature #310122, revision 13 Title: Revise Release Cycle openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Refilwe Seete (referenceseete) Partner organization: openSUSE.org Description: Move to an annual major release with an additional bug-fix remaster. An Example of How it Would Work: Every May* 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 September*, a bug-fix respin would be published. 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] Business case (Partner benefit): openSUSE.org: - <p>Move to an annual major release with an additional bug-fix remaster. - </p> - <p>An Example of How it Would Work:</p> - <p>Every May* a new major release of openSUSE is released. All the + Move to an annual major release with an additional bug-fix remaster. + An Example of How it Would Work: + Every May* 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.</p> - <p>Then in September*, a bug-fix respin would be published. 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.</p> - <p>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.</p> - <p>[*A different month might be considered more optimal by the - community]</p> + This release would be like every other release of openSUSE so far. + Then in September*, a bug-fix respin would be published. 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] Discussion: #1: Tom Zöhner (zoehneto) (2010-07-14 13:27:52) 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. #4: Refilwe Seete (referenceseete) (2010-07-14 18:16:04) (reply to #1) 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. #5: Tom Zöhner (zoehneto) (2010-07-14 19:12:31) (reply to #4) 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. #2: Stephen Shaw (decriptor) (2010-07-14 16:01:31) There is sled for those that want a more stable release #3: Refilwe Seete (referenceseete) (2010-07-14 17:51:14) (reply to #2) 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. #6: Otso Rajala (daedaluz) (2010-08-16 00:16:11) 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. -- openSUSE Feature: https://features.opensuse.org/310122