Feature changed by: Refilwe Seete (ReferenceSeete) Feature #310122, revision 2 Title: Annual Major Release + Bug Fix Release 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: PROS 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. This would reduce the feeling of being on an "upgrade - treadmill". 8. Provides us with something that makes openSUSE distinct - from other distros - a good period of support for every major release. - CONS 1. There's supposedly a large segment of Linux users that want new + openSUSE.org: And now with some formatting... + PROS +   + 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. This would reduce the feeling of being on + an "upgrade treadmill". +   + 8. Provides us with something that makes openSUSE distinct from other + distros - a good period of support for every major release. +   + CONS +   + 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 using major releases to get around their frustration with the software 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 and KDE. I don't think this is that big a - deal. The current 8-month release cycle already misses major versions - sometimes (for example OS 11.3 will have KDE 4.4.x while OS 11.4 will - have KDE 4.6.x). + is make the appropriate OBS repos more discoverable. +   + 2. openSUSE will miss a major update to GNOME and KDE. I don't think + this is that big a deal. The current 8-month release cycle already + misses major versions sometimes (for example OS 11.3 will have KDE 4.4. + x while OS 11.4 will have KDE 4.6.x). -- openSUSE Feature: https://features.opensuse.org/310122

Feature changed by: Refilwe Seete (ReferenceSeete) Feature #310122, revision 4 Title: Annual Major Release + Bug Fix Release 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: PROS 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. This would reduce the feeling of being on an "upgrade treadmill". 8. Provides us with something that makes openSUSE distinct from other distros - a good period of support for every major release.   CONS 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 using major releases to get around their frustration with the software 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 and KDE. I don't think this is that big a deal. The current 8-month release cycle already misses major versions sometimes (for example OS 11.3 will have KDE 4.4. x while OS 11.4 will have KDE 4.6.x). -- openSUSE Feature: https://features.opensuse.org/310122

Feature changed by: Stephen Shaw (decriptor) Feature #310122, revision 6 Title: Annual Major Release + Bug Fix Release 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: PROS 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. This would reduce the feeling of being on an "upgrade treadmill". 8. Provides us with something that makes openSUSE distinct from other distros - a good period of support for every major release.   CONS 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 using major releases to get around their frustration with the software 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 and KDE. I don't think this is that big a deal. The current 8-month release cycle already misses major versions sometimes (for example OS 11.3 will have KDE 4.4. x while OS 11.4 will have KDE 4.6.x). 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. + #2: Stephen Shaw (decriptor) (2010-07-14 16:01:31) + There is sled for those that want a more stable release -- openSUSE Feature: https://features.opensuse.org/310122

Feature changed by: Refilwe Seete (ReferenceSeete) Feature #310122, revision 8 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: PROS 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. This would reduce the feeling of being on an "upgrade treadmill". 8. Provides us with something that makes openSUSE distinct from other distros - a good period of support for every major release.   CONS 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 using major releases to get around their frustration with the software 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 and KDE. I don't think this is that big a deal. The current 8-month release cycle already misses major versions sometimes (for example OS 11.3 will have KDE 4.4. x while OS 11.4 will have KDE 4.6.x). 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. #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. -- openSUSE Feature: https://features.opensuse.org/310122

Feature changed by: Tom Zöhner (zoehneto) Feature #310122, revision 10 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: PROS 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. This would reduce the feeling of being on an "upgrade treadmill". 8. Provides us with something that makes openSUSE distinct from other distros - a good period of support for every major release.   CONS 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 using major releases to get around their frustration with the software 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 and KDE. I don't think this is that big a deal. The current 8-month release cycle already misses major versions sometimes (for example OS 11.3 will have KDE 4.4. x while OS 11.4 will have KDE 4.6.x). 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. -- openSUSE Feature: https://features.opensuse.org/310122

Feature changed by: Refilwe Seete (ReferenceSeete) Feature #310122, revision 12 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: PROS - 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. This would reduce the feeling of being on - an "upgrade treadmill". - 8. Provides us with something that makes openSUSE distinct from other - distros - a good period of support for every major release. + 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 + 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>   - CONS - 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 using major releases to get - around their frustration with the software 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 and KDE. I don't think - this is that big a deal. The current 8-month release cycle already - misses major versions sometimes (for example OS 11.3 will have KDE 4.4. - x while OS 11.4 will have KDE 4.6.x). 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

Feature changed by: Refilwe Seete (ReferenceSeete) Feature #310122, revision 14 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] +   + PROS + 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. This would reduce the feeling of being on + an "upgrade treadmill". + 8. Provides us with something that makes openSUSE distinct from other + distros - a good period of support for every major release. +   + CONS + 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 using major releases to get + around their frustration with the software 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 and KDE. I don't think + this is that big a deal. The current 8-month release cycle already + misses major versions sometimes (for example OS 11.3 will have KDE 4.4. + x while OS 11.4 will have KDE 4.6.x). +   Business case (Partner benefit): openSUSE.org:   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]   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

Feature changed by: Refilwe Seete (ReferenceSeete) Feature #310122, revision 16 Title: Extend Support Period/Revise Release Cycle openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Refilwe Seete (referenceseete) Partner organization: openSUSE.org Description:   PROS 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. + 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 + 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. This would reduce the feeling of being on - an "upgrade treadmill". - 8. Provides us with something that makes openSUSE distinct from other + 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.   CONS 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 + 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 using major releases to get - around their frustration with the software 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 and KDE. I don't think - this is that big a deal. The current 8-month release cycle already - misses major versions sometimes (for example OS 11.3 will have KDE 4.4. - x while OS 11.4 will have KDE 4.6.x). -   + 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). Business case (Partner benefit): openSUSE.org: 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.  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. + 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] 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