From what I'm reading in this thread, it sounds like an annual release would be beneficial all around starting with next years first annual kick-off of openSUSE 13.
With the exception of some logistics of how to handle the releases of associated software, (IMHO) these are after all separate from our OS. When GNOME or KDE releases their next version prior to the release of our OS, it will be handled just as any other software separate from the OS itself. Just as Firefox or LibreOffice or GIMP or any other software which is commonly used and packaged with our distribution, if a user chooses to upgrade those individual identities as they are made available from their respective development community then of course they may do so and we (openSUSE) should provide all reasonable support to help facilitate their operation on our platform without undue hardship to our programming team. Otherwise, as usual, an officially supported version of the same popular software will be provided with the next release as it always has been in the past. A good example of this is KDE 4.8 "officially" supported with 12.2 when 4.9 is out and available for those souls who wish to be "bleeding edge". On Mon, Sep 17, 2012 at 7:21 PM, Rajko <rmatov101@charter.net> wrote:
On Mon, 17 Sep 2012 08:59:41 +0200 "Dominique Leuenberger a.k.a DimStar" <DimStar@openSUSE.org> wrote:
...
- If we call it openSUSE 13, it reflects the year (and until 2099 we're safe with the version scheme)...
:)
Even further as 100 to 999 is just fine. First time our offspring will have to discuss new version scheme is next millennium. ( There will be no buffer overflow when third digit is added :)
A yearly release sounds intriguing, but 'official respins' with 'some' marketing coverage might be interesting to do then.
With one years release cycle it is actually mandatory to have respins. What that will bring:
* Obviously, buzz for a whole year :)
* Users will get newer software in a Tumbleweed fashion; unchanged base system with newer software including kernel device drivers. Respins can be Tumbleweed snapshots, which will have additional positive effect; in a case of problems that will require fallback to previous state, change will be not so drastic as it is now.
* Software integrators will have more time for a base system as more software updates will happen without backporting effort.
* More users will be able to try openSUSE when is well debugged and more suitable for them.
* From that group some will move to earlier releases, which at the end, when they come to the Factory, will increase integration support base - testers, bug reporters and debuggers.
* This will also correct current situation where installation mediums are always with some defects and always some group of users can't install without serious help.
* Problem-less installation will lower pressure on support channels for basic installation help, opening opportunity to discuss other software issues and improve quality of distribution.
In short, one year cycle and respins will solve few problem that project is facing right now, and at the same time increase user satisfaction.
...
Offering 'official respins' of openSUSE 13 + GNOME 3.10 (or whatever it will be called...)
The name for respins should be simple and in accordance with expectations of people that follow software development with major.minor part.
I don't buy in total simplification as the best option and the reason is exactly your example. * How to address release in a short form "13 + GNOME" instead of 13.1. * Also it is telling KDE users they don't have to look there, while it can be some improved software that they can use. A bit of mystery is good.
...
Of course, the most 'difficult' part with those respins would be compatibility with 'other desktops';
If we follow Tumbleweed example, then incompatible software that break other can't enter the main repo. Either, it must wait next release, or it can be offered as an unofficial Live CD, with clear statement that is not suitable to install another desktops and give a reason for that. I don't think that many will complain about that limitation.
Best regards, Dominique
-- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org