Mailinglist Archive: opensuse-project (539 mails)

< Previous Next >
Re: [opensuse-project] Re: First Survey on openSUSE Version naming is open now
On Wed, 2011-03-16 at 08:50 +1100, Helen South wrote:
On Wed, Mar 16, 2011 at 7:51 AM, Jim Henderson <hendersj@xxxxxxxxx> 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >