Mailinglist Archive: opensuse-project (465 mails)

[Per Jessen <per@xxxxxxxxxxxx>]

Stephan Kulow wrote:

> Am Montag 12 Juli 2010 schrieb Michael Loeffler:
> > On Monday 12 July 2010 15:07:18 Pavol Rusnak wrote:
> > > On 07/12/2010 03:05 PM, Peter Albrecht wrote:
> > > > Is it really? To me it always has been obvious that the numbering
> > > > scheme was as Chuck mentioned.
> > >
> > > Exactly, but it seems this is going to change now, because we'll be
> > > having 11.4 and maybe even 11.5 (read email by Michael Loeffler
> > > above in this thread). If we want to avoid more confusion, we
> > > really have to document this.
> >
> > Fully agreed, it needs documentation. Its better then guessing.
> > I strongly propose to give the upcoming version the name openSUSE
> > 11.4 as rushing this makes things more likely worse then they are and
> > I don't see agreement on any of the discussed version schemes. I'm
> > oppose to change the scheme to the sake of change but I'm open to
> > change it to improve it.
> OK, so let's kill this thread: the openSUSE versioning scheme is as
> is: we have 11.X till we see a reason to jump to 12.0 - from then on
> we'll have 12.X. This X is increasing every 8 months.

Sounds good to me. 

> 3 months before release of every 11.X we'll discuss on
> opensuse-factory if the changes in 11.X are worth a 12.0. 

Hmm, I'm not very fond of that - couldn't we try to plan ahead and
decide the next major released based on major changes "queued up"?  

> The board then will decide - this is not exactly a technical decision,
> it's only a collection of gut feelings that need to be collected. IMO
> a board's task.

Agree.

> Reasons for a 12.0 from my point of view are:
> - drastic changes in user experience during installation or the way
> linux works
> - drastic changes in the base system that make it much harder than
> usual to do live updates.
>
> But again: I wouldn't try to describe the exact algorithm a new major
> version is picked upon, but make it an open process triggered by a
> timeline.

How about:

1) always assume the next release is a minor release

This means any major change cannot be incorporated, and will have to be
scheduled. 

2) when enough major changes are scheduled, the next release becomes a
major. 




-- 
Per Jessen, Zürich (31.6°C)

--
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx