(release) versioning

(release) versioning

[Jan Beulich]

All,

on the hackathon we also discussed possibly changing the versioning
of Xen. The main rationale for the proposal is that (just like in many
other software projects) version numbers (in particular the major
one) currently don't really convey much information. The proposal is
to take gcc's new versioning scheme as a basis (i.e. I'm not going to
claim that the below is an exact copy of theirs): Major releases
always increment the major version number. Minor version 0 is
reserved to the development cycle, i.e. the first release in any
release series would be 5.1.0. RCs would be expressed through the
3rd digit, i.e. the first RC of the currently being worked on release
would be 5.0.1 (there was some debate as to whether, despite
being redundant, to attach -rc1 to it to make clear this is not an
actual release).

So comparing current and new schemes things would go

	OLD			NEW
	4.6-unstable		5.0-unstable (or 5.0.0)
	4.6.0-rc1			5.0.1 (-rc1)
	...			...
	4.6.0-rcN			5.0.N (-rcN)
	4.6.0			5.1.0
	4.6.1-rc1			5.1.1 (-rc1)
	...			...
	4.6.1			5.2.0

This additionally has the benefit that taking only the numeric
part of the version string then would sort properly.

Any comments or alternative proposals are welcome.

Regards, Jan

Re: (release) versioning

[Andrew Cooper]

On 05/05/15 16:54, Jan Beulich wrote:
> All,
>
> on the hackathon we also discussed possibly changing the versioning
> of Xen. The main rationale for the proposal is that (just like in many
> other software projects) version numbers (in particular the major
> one) currently don't really convey much information. The proposal is
> to take gcc's new versioning scheme as a basis (i.e. I'm not going to
> claim that the below is an exact copy of theirs): Major releases
> always increment the major version number. Minor version 0 is
> reserved to the development cycle, i.e. the first release in any
> release series would be 5.1.0. RCs would be expressed through the
> 3rd digit, i.e. the first RC of the currently being worked on release
> would be 5.0.1 (there was some debate as to whether, despite
> being redundant, to attach -rc1 to it to make clear this is not an
> actual release).
>
> So comparing current and new schemes things would go
>
> 	OLD			NEW
> 	4.6-unstable		5.0-unstable (or 5.0.0)
> 	4.6.0-rc1			5.0.1 (-rc1)
> 	...			...
> 	4.6.0-rcN			5.0.N (-rcN)
> 	4.6.0			5.1.0
> 	4.6.1-rc1			5.1.1 (-rc1)
> 	...			...
> 	4.6.1			5.2.0
>
> This additionally has the benefit that taking only the numeric
> part of the version string then would sort properly.
>
> Any comments or alternative proposals are welcome.

+1 (relayed from the hackathon)

~Andrew

Re: (release) versioning

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 2368 bytes --]

On Tue, 2015-05-05 at 18:05 +0100, Andrew Cooper wrote:
> On 05/05/15 16:54, Jan Beulich wrote:
> > All,
> >
> > on the hackathon we also discussed possibly changing the versioning
> > of Xen. The main rationale for the proposal is that (just like in many
> > other software projects) version numbers (in particular the major
> > one) currently don't really convey much information. The proposal is
> > to take gcc's new versioning scheme as a basis (i.e. I'm not going to
> > claim that the below is an exact copy of theirs): Major releases
> > always increment the major version number. Minor version 0 is
> > reserved to the development cycle, i.e. the first release in any
> > release series would be 5.1.0. RCs would be expressed through the
> > 3rd digit, i.e. the first RC of the currently being worked on release
> > would be 5.0.1
>
I like this.

>  (there was some debate as to whether, despite
> > being redundant, to attach -rc1 to it to make clear this is not an
> > actual release).
> >
I see the point of making it clear enough that it's an RC, but then I
don't like the redundancy. I.e., seeing something liek 5.0.1-rc1,
5.0.2-rc2, 5.0.3-rc3 would make me wonder what happened to 5.0.2-rc1, to
5.0.3-rc1 and -rc2 etc.

> > So comparing current and new schemes things would go
> >
> > 	OLD			NEW
> > 	4.6-unstable		5.0-unstable (or 5.0.0)
> > 	4.6.0-rc1			5.0.1 (-rc1)
> > 	...			...
> > 	4.6.0-rcN			5.0.N (-rcN)
> > 	4.6.0			5.1.0
> > 	4.6.1-rc1			5.1.1 (-rc1)
> > 	...			...
> > 	4.6.1			5.2.0
> >
It also feels a bit odd here, still if we keep the -rcX, that 5.0.N-rcN
is the release candidate for 5.1.0... Wouldn't one then be the least
surprised by just seeing the -rcN part dropped and 5.0.N be released?

> > This additionally has the benefit that taking only the numeric
> > part of the version string then would sort properly.
> >
> > Any comments or alternative proposals are welcome.
> 
Well, if we decide to keep the -rcX, then the 3rd digit will be:
 - always .0 for actual releases
 - always the same as -rc* for RCs

so it looks to me that we can just kill it and have:

 5.0-unstable
   5.1-rc1
   5.1-rc2
   ...
   5.1-rcN
 5.1
   5.2-rc1
   ...
 5.3

> +1 (relayed from the hackathon)
> 
All the above being said and FWIW, overall, +1 from me too.

Regards,
Dario

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (release) versioning

[Jan Beulich]

>>> On 06.05.15 at 01:15, <dario.faggioli@citrix.com> wrote:
> Well, if we decide to keep the -rcX, then the 3rd digit will be:
>  - always .0 for actual releases
>  - always the same as -rc* for RCs
> 
> so it looks to me that we can just kill it and have:
> 
>  5.0-unstable
>    5.1-rc1
>    5.1-rc2
>    ...
>    5.1-rcN
>  5.1
>    5.2-rc1
>    ...
>  5.3

No, that would break sortability on solely the number part again. Did
you look at IanC's adjustment proposal (dropping just the redundant
number, i.e. 5.0.1-rc)?

Jan

Re: (release) versioning

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 732 bytes --]

On Wed, 2015-05-06 at 12:54 +0100, Jan Beulich wrote:
> >>> On 06.05.15 at 01:15, <dario.faggioli@citrix.com> wrote:
> > Well, if we decide to keep the -rcX, then the 3rd digit will be:
> >  - always .0 for actual releases
> >  - always the same as -rc* for RCs
> > 
> > so it looks to me that we can just kill it and have:
> > 
> >  5.0-unstable
> >    5.1-rc1
> >    5.1-rc2
> >    ...
> >    5.1-rcN
> >  5.1
> >    5.2-rc1
> >    ...
> >  5.3
> 
> No, that would break sortability on solely the number part again. 
>
Yeah, I see.

> Did
> you look at IanC's adjustment proposal (dropping just the redundant
> number, i.e. 5.0.1-rc)?
>
Just now, and I like it, as it is non-redundant as well.

Dario

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (release) versioning

[Wei Liu]

On Tue, May 05, 2015 at 04:54:01PM +0100, Jan Beulich wrote:
> All,
> 
> on the hackathon we also discussed possibly changing the versioning
> of Xen. The main rationale for the proposal is that (just like in many
> other software projects) version numbers (in particular the major
> one) currently don't really convey much information. The proposal is
> to take gcc's new versioning scheme as a basis (i.e. I'm not going to
> claim that the below is an exact copy of theirs): Major releases
> always increment the major version number. Minor version 0 is
> reserved to the development cycle, i.e. the first release in any
> release series would be 5.1.0. RCs would be expressed through the
> 3rd digit, i.e. the first RC of the currently being worked on release
> would be 5.0.1 (there was some debate as to whether, despite
> being redundant, to attach -rc1 to it to make clear this is not an
> actual release).
> 
> So comparing current and new schemes things would go
> 
> 	OLD			NEW
> 	4.6-unstable		5.0-unstable (or 5.0.0)
> 	4.6.0-rc1			5.0.1 (-rc1)
> 	...			...
> 	4.6.0-rcN			5.0.N (-rcN)
> 	4.6.0			5.1.0
> 	4.6.1-rc1			5.1.1 (-rc1)
> 	...			...
> 	4.6.1			5.2.0
> 
> This additionally has the benefit that taking only the numeric
> part of the version string then would sort properly.
> 
> Any comments or alternative proposals are welcome.
> 

One exceptional situation is that we had 4.1.6 and 4.1.6.1. I don't
expect that to happen very often, but we do make mistakes in the release
process and figure out we need to release a slightly updated version.
How does this fit into the proposed scheme?

Overall I think making the version number more meaningful is a good
idea.

Wei.

> Regards, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: (release) versioning

[Jan Beulich]

>>> On 06.05.15 at 09:21, <wei.liu2@citrix.com> wrote:
> On Tue, May 05, 2015 at 04:54:01PM +0100, Jan Beulich wrote:
>> All,
>> 
>> on the hackathon we also discussed possibly changing the versioning
>> of Xen. The main rationale for the proposal is that (just like in many
>> other software projects) version numbers (in particular the major
>> one) currently don't really convey much information. The proposal is
>> to take gcc's new versioning scheme as a basis (i.e. I'm not going to
>> claim that the below is an exact copy of theirs): Major releases
>> always increment the major version number. Minor version 0 is
>> reserved to the development cycle, i.e. the first release in any
>> release series would be 5.1.0. RCs would be expressed through the
>> 3rd digit, i.e. the first RC of the currently being worked on release
>> would be 5.0.1 (there was some debate as to whether, despite
>> being redundant, to attach -rc1 to it to make clear this is not an
>> actual release).
>> 
>> So comparing current and new schemes things would go
>> 
>> 	OLD			NEW
>> 	4.6-unstable		5.0-unstable (or 5.0.0)
>> 	4.6.0-rc1			5.0.1 (-rc1)
>> 	...			...
>> 	4.6.0-rcN			5.0.N (-rcN)
>> 	4.6.0			5.1.0
>> 	4.6.1-rc1			5.1.1 (-rc1)
>> 	...			...
>> 	4.6.1			5.2.0
>> 
>> This additionally has the benefit that taking only the numeric
>> part of the version string then would sort properly.
>> 
>> Any comments or alternative proposals are welcome.
> 
> One exceptional situation is that we had 4.1.6 and 4.1.6.1. I don't
> expect that to happen very often, but we do make mistakes in the release
> process and figure out we need to release a slightly updated version.
> How does this fit into the proposed scheme?

I think we would just attach a .1 to the previous version the same
way we did there, i.e. 5.2.0.1.

Jan

Re: (release) versioning

[David Vrabel]

On 06/05/15 08:25, Jan Beulich wrote:
>>>> On 06.05.15 at 09:21, <wei.liu2@citrix.com> wrote:
>> On Tue, May 05, 2015 at 04:54:01PM +0100, Jan Beulich wrote:
>>> All,
>>>
>>> on the hackathon we also discussed possibly changing the versioning
>>> of Xen. The main rationale for the proposal is that (just like in many
>>> other software projects) version numbers (in particular the major
>>> one) currently don't really convey much information. The proposal is
>>> to take gcc's new versioning scheme as a basis (i.e. I'm not going to
>>> claim that the below is an exact copy of theirs): Major releases
>>> always increment the major version number. Minor version 0 is
>>> reserved to the development cycle, i.e. the first release in any
>>> release series would be 5.1.0. RCs would be expressed through the
>>> 3rd digit, i.e. the first RC of the currently being worked on release
>>> would be 5.0.1 (there was some debate as to whether, despite
>>> being redundant, to attach -rc1 to it to make clear this is not an
>>> actual release).
>>>
>>> So comparing current and new schemes things would go
>>>
>>> 	OLD			NEW
>>> 	4.6-unstable		5.0-unstable (or 5.0.0)
>>> 	4.6.0-rc1			5.0.1 (-rc1)
>>> 	...			...
>>> 	4.6.0-rcN			5.0.N (-rcN)
>>> 	4.6.0			5.1.0
>>> 	4.6.1-rc1			5.1.1 (-rc1)
>>> 	...			...
>>> 	4.6.1			5.2.0
>>>
>>> This additionally has the benefit that taking only the numeric
>>> part of the version string then would sort properly.
>>>
>>> Any comments or alternative proposals are welcome.
>>
>> One exceptional situation is that we had 4.1.6 and 4.1.6.1. I don't
>> expect that to happen very often, but we do make mistakes in the release
>> process and figure out we need to release a slightly updated version.
>> How does this fit into the proposed scheme?
> 
> I think we would just attach a .1 to the previous version the same
> way we did there, i.e. 5.2.0.1.

What happens if this minor fixup itself needs a micro fixup?  Do we then
have 5.2.0.1.1? etc. etc.

Why not always bump the minor version regardless of how small the change
was?

(I would also like the bike shed in purple with yellow stripes).

David

Re: (release) versioning

[Jan Beulich]

>>> On 06.05.15 at 12:37, <david.vrabel@citrix.com> wrote:
> On 06/05/15 08:25, Jan Beulich wrote:
>>>>> On 06.05.15 at 09:21, <wei.liu2@citrix.com> wrote:
>>> One exceptional situation is that we had 4.1.6 and 4.1.6.1. I don't
>>> expect that to happen very often, but we do make mistakes in the release
>>> process and figure out we need to release a slightly updated version.
>>> How does this fit into the proposed scheme?
>> 
>> I think we would just attach a .1 to the previous version the same
>> way we did there, i.e. 5.2.0.1.
> 
> What happens if this minor fixup itself needs a micro fixup?  Do we then
> have 5.2.0.1.1? etc. etc.

No, that would (naturally I would say) become 5.2.0.2.

> Why not always bump the minor version regardless of how small the change
> was?

That's certainly an option, but we chose the other route on the one
occasion when we needed it.

> (I would also like the bike shed in purple with yellow stripes).

Of course.

Jan

Re: (release) versioning

[David Vrabel]

On 06/05/15 11:52, Jan Beulich wrote:
>>>> On 06.05.15 at 12:37, <david.vrabel@citrix.com> wrote:
>> On 06/05/15 08:25, Jan Beulich wrote:
>>>>>> On 06.05.15 at 09:21, <wei.liu2@citrix.com> wrote:
>>>> One exceptional situation is that we had 4.1.6 and 4.1.6.1. I don't
>>>> expect that to happen very often, but we do make mistakes in the release
>>>> process and figure out we need to release a slightly updated version.
>>>> How does this fit into the proposed scheme?
>>>
>>> I think we would just attach a .1 to the previous version the same
>>> way we did there, i.e. 5.2.0.1.
>>
>> What happens if this minor fixup itself needs a micro fixup?  Do we then
>> have 5.2.0.1.1? etc. etc.
> 
> No, that would (naturally I would say) become 5.2.0.2.
> 
>> Why not always bump the minor version regardless of how small the change
>> was?
> 
> That's certainly an option, but we chose the other route on the one
> occasion when we needed it.

Fair enough, I don't really mind.

David

Re: (release) versioning

[Ian Campbell]

On Tue, 2015-05-05 at 16:54 +0100, Jan Beulich wrote:
> All,
> 
> on the hackathon we also discussed possibly changing the versioning
> of Xen.

Sorry I missed this, I had a clash.

>  The main rationale for the proposal is that (just like in many
> other software projects) version numbers (in particular the major
> one) currently don't really convey much information. The proposal is
> to take gcc's new versioning scheme as a basis (i.e. I'm not going to
> claim that the below is an exact copy of theirs): Major releases
> always increment the major version number. Minor version 0 is
> reserved to the development cycle, i.e. the first release in any
> release series would be 5.1.0. RCs would be expressed through the
> 3rd digit, i.e. the first RC of the currently being worked on release
> would be 5.0.1 (there was some debate as to whether, despite
> being redundant, to attach -rc1 to it to make clear this is not an
> actual release).
> 
> So comparing current and new schemes things would go
> 
> 	OLD			NEW
> 	4.6-unstable		5.0-unstable (or 5.0.0)
> 	4.6.0-rc1			5.0.1 (-rc1)
> 	...			...
> 	4.6.0-rcN			5.0.N (-rcN)
> 	4.6.0			5.1.0
> 	4.6.1-rc1			5.1.1 (-rc1)
> 	...			...
> 	4.6.1			5.2.0
> 
> This additionally has the benefit that taking only the numeric
> part of the version string then would sort properly.
> 
> Any comments or alternative proposals are welcome.

If we had no historical versioning schemes I'd be completely happy with
this but I'm worried that people would naturally assume 5.0.1 to mean
"first rc of 5.0" based on historical use. Perhaps that's just a
communications issue (and switching to 5.X at the same time might help).

For example I had no idea until now that gcc 5.0.1 was a prerelease and
not a proper release, but then I don't really follow gcc development.

Adding a trailing redundant -rc (with or without the N) might help, and
omitting the N (e.g. "5.0.1-rc") would reduce the redundancy to near
zero.

Was 5.0-rcN leading to a 5.0 release considered and ruled out? I suppose
it looses the benefit of the numeric portion sorting properly.

Ian.

> 
> Regards, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: (release) versioning

[Jan Beulich]

>>> On 06.05.15 at 11:02, <ian.campbell@citrix.com> wrote:
> Adding a trailing redundant -rc (with or without the N) might help, and
> omitting the N (e.g. "5.0.1-rc") would reduce the redundancy to near
> zero.

Good suggestion.

> Was 5.0-rcN leading to a 5.0 release considered and ruled out?

It wasn't mentioned in the discussion I think, but ...

> I suppose
> it looses the benefit of the numeric portion sorting properly.

... based on this I had rules it out before that (and hence didn't
even bring it up as a possibility). And using 5.0-rcN to lead to a
5.1.0 release would become odd/misleading the latest for
subsequent stable release RCs.

Jan

Re: (release) versioning

[Ian Campbell]

On Wed, 2015-05-06 at 11:12 +0100, Jan Beulich wrote:
> >>> On 06.05.15 at 11:02, <ian.campbell@citrix.com> wrote:
> > Adding a trailing redundant -rc (with or without the N) might help, and
> > omitting the N (e.g. "5.0.1-rc") would reduce the redundancy to near
> > zero.
> 
> Good suggestion.
> 
> > Was 5.0-rcN leading to a 5.0 release considered and ruled out?
> 
> It wasn't mentioned in the discussion I think, but ...
> 
> > I suppose
> > it looses the benefit of the numeric portion sorting properly.
> 
> ... based on this I had rules it out before that (and hence didn't
> even bring it up as a possibility). And using 5.0-rcN to lead to a
> 5.1.0 release would become odd/misleading the latest for
> subsequent stable release RCs.

Right, I had meant 5.0-rc leading to a 5.0(.0) release.

(Anyway I'm ok with "5.0.1-rc", so it doesn't matter)
Ian.

Re: (release) versioning

[Konrad Rzeszutek Wilk]

On Tue, May 05, 2015 at 04:54:01PM +0100, Jan Beulich wrote:
> All,
> 
> on the hackathon we also discussed possibly changing the versioning
> of Xen. The main rationale for the proposal is that (just like in many
> other software projects) version numbers (in particular the major
> one) currently don't really convey much information. The proposal is
> to take gcc's new versioning scheme as a basis (i.e. I'm not going to
> claim that the below is an exact copy of theirs): Major releases
> always increment the major version number. Minor version 0 is
> reserved to the development cycle, i.e. the first release in any
> release series would be 5.1.0. RCs would be expressed through the
> 3rd digit, i.e. the first RC of the currently being worked on release
> would be 5.0.1 (there was some debate as to whether, despite
> being redundant, to attach -rc1 to it to make clear this is not an
> actual release).
> 
> So comparing current and new schemes things would go
> 
> 	OLD			NEW
> 	4.6-unstable		5.0-unstable (or 5.0.0)
> 	4.6.0-rc1			5.0.1 (-rc1)
> 	...			...
> 	4.6.0-rcN			5.0.N (-rcN)
> 	4.6.0			5.1.0
> 	4.6.1-rc1			5.1.1 (-rc1)
> 	...			...
> 	4.6.1			5.2.0
> 
> This additionally has the benefit that taking only the numeric
> part of the version string then would sort properly.
> 
> Any comments or alternative proposals are welcome.

I am OK with the mechanism as is and not sure why it would need
changing. I know you are saying that the existing mechanism
does not convery much information but I think the 'rcX'appended
to the version tag is enough to tell us when there is an RC and
when there is a new release.


> 
> Regards, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: (release) versioning

[George Dunlap]

On Wed, May 6, 2015 at 3:58 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> I am OK with the mechanism as is and not sure why it would need
> changing. I know you are saying that the existing mechanism
> does not convery much information but I think the 'rcX'appended
> to the version tag is enough to tell us when there is an RC and
> when there is a new release.

I think part of the thing I don't like about the current scheme is
that bumping a major version number may communicate "something REALLY
BIG has changed", when nothing really big has changed.

Which leaves us either not changing the major number ever (and getting
Xen 4.87 or things like that) or changing it based on some arbitrary
threshold, like "20 seems like a big number, so we'll have Linux 4.0
rather than Linux 3.20".

I could be convinced that we should bump the major version every 5
years or something.  As it happens, Xen 3.0 was released in 2005, and
Xen 4.0 was released in 2010; so maybe making our upcoming release
version Xen 5.0, and having the first release in 2020 be Xen 6.0?

That doesn't give us the nice sort-ability that Jan's proposal does,
but at least "5-year epoch" is roughly useful and not completely
arbitrary.

 -George

Re: (release) versioning

[George Dunlap]

On Tue, May 5, 2015 at 4:54 PM, Jan Beulich <JBeulich@suse.com> wrote:
> All,
>
> on the hackathon we also discussed possibly changing the versioning
> of Xen. The main rationale for the proposal is that (just like in many
> other software projects) version numbers (in particular the major
> one) currently don't really convey much information. The proposal is
> to take gcc's new versioning scheme as a basis (i.e. I'm not going to
> claim that the below is an exact copy of theirs): Major releases
> always increment the major version number. Minor version 0 is
> reserved to the development cycle, i.e. the first release in any
> release series would be 5.1.0. RCs would be expressed through the
> 3rd digit, i.e. the first RC of the currently being worked on release
> would be 5.0.1 (there was some debate as to whether, despite
> being redundant, to attach -rc1 to it to make clear this is not an
> actual release).
>
> So comparing current and new schemes things would go
>
>         OLD                     NEW
>         4.6-unstable            5.0-unstable (or 5.0.0)
>         4.6.0-rc1                       5.0.1 (-rc1)
>         ...                     ...
>         4.6.0-rcN                       5.0.N (-rcN)
>         4.6.0                   5.1.0
>         4.6.1-rc1                       5.1.1 (-rc1)
>         ...                     ...
>         4.6.1                   5.2.0

I just noticed something a bit strange about this scheme: When the
second digit is '0', it means "development" and non-zero it means
"release"; but when the third digit is zero, it means "release", and
non-zero it means "development" (or "rc").

I guess there's not really a way to get around that.  In any case, I'm
fine with having a little bit of quirkiness.  Having just "-rc" rather
than "-rcN" as a tag sounds fine to me.

Regarding 5.3.0.1 -- now once again you have a 4th digit where
non-zero means "release"; and do we need RCs for this?  Do we have
5.3.0.0.1-rc, and then 5,3,0.1 which is stable?

Personally I agree with David's taste in bike shed color -- I think if
we find a major problem with 5.3.0, we should just release 5.4.0
shortly afterwards.  But this will presumably happen so rarely it
won't really matter all that much (particularly now that we have much
more thorough testing before a release).

So how do we officially decide on this?  Do we wait for 2 weeks on
this thread for objections, then do a formal proposal?

 -George

Re: (release) versioning

[Jan Beulich]

>>> On 06.05.15 at 17:01, <dunlapg@umich.edu> wrote:
> Regarding 5.3.0.1 -- now once again you have a 4th digit where
> non-zero means "release"; and do we need RCs for this?  Do we have
> 5.3.0.0.1-rc, and then 5,3,0.1 which is stable?

No, in such cases I don't expect any RCs, just another release
(just like was done for 4.1.6.1).

> So how do we officially decide on this?  Do we wait for 2 weeks on
> this thread for objections, then do a formal proposal?

Yeah, that's what's intended I think. Lars?

Jan

Re: (release) versioning

[Lars Kurth]

On 06/05/2015 16:44, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.05.15 at 17:01, <dunlapg@umich.edu> wrote:
>> Regarding 5.3.0.1 -- now once again you have a 4th digit where
>> non-zero means "release"; and do we need RCs for this?  Do we have
>> 5.3.0.0.1-rc, and then 5,3,0.1 which is stable?
>
>No, in such cases I don't expect any RCs, just another release
>(just like was done for 4.1.6.1).

Couldn't we just go for something like -a, -b, -c instead if we make a
mistake
Or push up the 2nd number straight away, from say 5.0 to 5.1

I would also say that for public release numbering (aka published final
releases, we drop everything after major.minor

>
>> So how do we officially decide on this?  Do we wait for 2 weeks on
>> this thread for objections, then do a formal proposal?
>
>Yeah, that's what's intended I think. Lars?


I would summarise the outcome of the thread and ask the committers to
formally vote on it

Regards
Lars

Re: (release) versioning

[Tim Deegan]

Hi,

At 16:54 +0100 on 05 May (1430844841), Jan Beulich wrote:
> So comparing current and new schemes things would go
> 
> 	OLD			NEW
> 	4.6-unstable		5.0-unstable (or 5.0.0)
> 	4.6.0-rc1			5.0.1 (-rc1)
> 	...			...
> 	4.6.0-rcN			5.0.N (-rcN)
> 	4.6.0			5.1.0
> 	4.6.1-rc1			5.1.1 (-rc1)
> 	...			...
> 	4.6.1			5.2.0
> 

I prefer the old scheme to the proposed one.  In particular:
 - it's not at all clear to an outsider that 5.0.x is
   unstable and unsupported.
 - main releases of Xen will always be "x.1.0", which makes them
   look like point releases; all the more so because actual point
   releases will be "x.2.0" &c.

If the problem is that the major version number doesn't mean anything,
then we could just drop it.   E.g. more like:

 	OLD			NEW
 	4.6-unstable		6-unstable
 	4.6.0-rc1		6.0-rc1
 	...			...
 	4.6.0-rcN		6.0-rcN
 	4.6.0			6.0
 	4.6.1-rc1		6.1-rc1
 	...			...
 	4.6.1			6.1
        4.7-unstable		7-unstable

> This additionally has the benefit that taking only the numeric
> part of the version string then would sort properly.

With s/6.0/6.0-release/ then the scheme above sorts OK too.  I don't
see why being able to sort RCs based only on the numbers would be
useful.

Tim.