On Wed, 2011-03-16 at 08:50 +1100, Helen South wrote:
On Wed, Mar 16, 2011 at 7:51 AM, Jim Henderson
wrote: 1) introduce planning of major releases of openSUSE. 2) stop using major.minor version numbers of openSUSE.
I have sofar been advocating 1), but as the powers that be do not seem overly inclined to taking that path, 2) is the alternative. I would much prefer "openSUSE 27" with no implied meaning over "openSUSE 13.4" with an implied ".4" meaning of no value.
Arguably, though, there'd be no difference between 27 and 28, why not go from 20 to 30?
When it comes down to it, release versioning is more of a marketing exercise than it is a project management/product management exercise (versioning is important to identify changes in SVN, for example, but those revision numbers only have meaning in that they are a measure of timed events - commits - that show a progression).
<snip for brevity>
So from the standpoint of a marketing discussion, I agree, major.minor doesn't make much sense unless the user can actually discern the meaning of a particular change in version number. Otherwise it's arbitrary.
Jim --
One of my issues with major/minor is that we then have the pressure to conform to Major/Minor. The progression must be followed, but what if upstream have no major changes and nothing much is happening with the kernel?
What constitutes 'major'? Is it seen as partisan to mark a significant development in one desktop or another? Can one major follow another immediately if some major development occurs?
My impression is that often change is a gradual, almost organic process with a lot outside of our control. The 11.4 to 12 step could be regarded as a major/minor, or it could simply be an abbreviated incremental process. I gather it is seen somewhat as a step to 'major' but it concerns me that this means that to go to 12, we are actively looking for reasons to make it major (without stepping on KDE toes over Gnome SHELL, for instance).
I worry about painting ourselves into a corner by formalizing the major/minor idea. Some sort of flexibility would need to be built in, possibly to the release schedule to allow for desktop or kernel delays.
Not necessarily negatives but just a couple of issues that would need to be addressed if we went that way.
I agree somewhat with Chuck; this is something that should probably resolved quite quickly.
cheers,
Helen
From a marketing/press standpoint, there's definitely an implied "major/minor" with our current versioning standard. It's been easy and understandable for us that there is no major/minor, but that's cuz we're familiar and know how it works. Back when I went from 10.3 to 11 (before I truly understood the process) I really thought 11 was a major release and as an end user I was disappointed to not see anything so drastically different.
The same problem goes for press reviews. Unless they take the time to understand that 11.3 is a new version rather than an updated version, they seem less inclined to write about us. This has always been a problem and we see a declining of new downloads with each "minor" release. Every new release needs to have awesome noise and not "here's the latest patched openSUSE review." It's also misleading because people view .x as meaning "a fixed version of the major release." And it sets their expectations when they try it when they're focused on some bad experience they might have had with a "major" release. We want each new release to be viewed objectively by all parties, not with baggage. Whatever our new versioning scheme will be, it needs to be clear right out of the gate what it means, or we will forever be struggling with the added effort of making clear in our marketing efforts that this is a *NEW* release, not a *patched* release. It adds overhead for us to dispel misperceptions and myths when we can focus more energy on "Hey... we're putting out yet another awesome release, folks!" Bryen M Yunashko openSUSE Marketing Team -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org