ceph versions

ceph versions

[Sage Weil]

Hammer will most likely be v0.94[.x].  We're getting awfully close to 
0.99, though, which makes many people think 1.0 or 1.00 (isntead of 
0.100), and the current versioning is getting a bit silly.  So let's talk 
about alternatives!

Here are a few of options:

-- Option A -- "doubles and triples"

X.Y[.Z]

 - Increment X at the start of each major dev cycle (hammer, infernalis)
 - Increment Y for each iteration during that cycle
 - Eventually decide it's good and start adding .Z for the stable fixes.

For example,

 1.0 first infernalis dev release
 1.1 dev release
 ...
 1.8 infernalis rc
 1.9 infernalis final
 1.9.1 stable update 
 1.9.2 stable update 
 ...
 2.0 first j (jewel?) dev release
 2.1 next dev release
 ...
 2.8 final j
 2.8.x stable j releases

Q: How do I tell if it's a stable release?
A: It is a triple instead of a double.

Q: How do I tell if this is the final release in the series?
A: Nobody knows that until we start doing stable updates; see above.


-- Option B -- "even/odd"

X.Y.Z

 - if Y is even, this is a stable series
 - if Y is odd, this is a dev release
 - increment X when something major happens

 1.0 hammer final
 1.0.1 stable/bugfix
 1.0.2 stable
 1.0.3 stable
 ...
 1.1.0 infernalis dev release
 1.1.1 infernalis dev release
 1.1.2 infernalis dev release
 ...
 1.2.0 infernalis final
 1.2.1 stable branch
 ...
 1.3.0 j-release dev
 1.3.1 j-release dev
 1.3.2 j-release dev
 ...
 1.4.0 j-release final
 1.4.1 stable
 1.4.1 stable

Q: How do I tell if it's a stable release?
A: Second item is even.


-- Option C -- "semantic"

major.minor.patch

- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible 
manner, and
- PATCH version when you make backwards-compatible bug fixes.

 1.0.0 hammer final
 1.0.1 bugfix
 1.0.1 bugfix
 1.0.1 bugfix
 1.1 infernalis dev release
 1.2 infernalis dev release
 2.0 infernalis dev release
 2.1 infernalis dev release
 2.2 infernalis dev release
 2.3 infernalis final
 2.3.0 bugfix
 2.3.1 bugfix
 2.3.2 bugfix
 2.4 j dev release
 ...
 2.14 j final
 2.14.0 bugfix
 2.14.1 bugfix
 ...
 2.15 k dev
 ..
 3.3 k final
 3.3.1 bugfix
 ...
 
Q: How do I tell what named release series this is?
A: As with the others, you just have to know.

Q: How do we distinguish between stable-series updates and dev updates?
A: Stable series are triples.

Q: How do I know if I can downgrade?
A: The major hasn't changed.

Q: Really?
A: Well, maybe.  We haven't dealt with downgrades yet so this assumes we 
get it right (and test it).  We may not realize there is a 
backward-incompatible change right away and only discover it later during 
testing, at which point the versions are fixed; we'd probably bump the 
*next* release in response.


-- Option D -- "labeled"

X.Y-{dev,rc,release}Z

 - Increment Y on each major named release
 - Increment X if it's a major major named release (bigger change 
than usual)
 - Use dev, rc, or release prefix to clearly label what type of release 
this is
 - Increment Z for stable updates

 1.0-dev1 first infernalis dev release
 1.0-dev2 another dev release
 ...
 1.0-rc1 first rc
 1.0-rc2 next rc
 1.0-release1 final release
 1.0-release2 stable update
 1.0-release3 stable update
 1.1-dev1 first cut for j-release
 1.1-dev2 ...
 ...
 1.1-rc1
 1.1-release1 stable
 1.1-release2 stable
 1.1-release3 stable

Q: How do I tell what kind of release this is?
A: Look at the string embedded in the version

Q: Will these funny strings confuse things that sort by version?
A: I don't think so.


-- Option E -- "ubuntu"

YY.MM[.Z]

 - YY is year, MM is month of release
 - Z for stable updates

 15.03 hammer final
 15.03.1 bugfix
 15.03.2 bugfix
 ...
 15.04 infernalis dev
 15.05 infernalis dev
 ...
 15.07 infernalis final
 15.07.1 bugfix
 15.07.2 bugfix
 ...

Q: What if we have more than one dev release a month?  Like, on a 2 weeks 
schedule, as we have been.
A: We move to monthly dev releases.  Or, we put an 'a' or 'b' suffix on 
there?  Meh.

Q: How do I tell if it's a stable release?
A: It's a triple.


-- Option F -- "flat"

X[.Y]

 - increment X on every release, regardless of whether it is a named 
release or not
 - add a .Y (or .0) if it is a stable release

 1.0 hammer final
 1.1 bugfix
 1.2 bugfix
 ...
 2 infernalis dev
 3 infernalis dev
 ...
 8 infernalis rc
 9.0 infernalis final
 9.1 bugfix
 ...
 10 j dev
 11 j dev
 12 j dev
 ...
 17.0 j final
 17.1 j bugfix
 ...

Q: What if the number gets big?
A: Too late!

Q: How do I tell if it's a stable release?
A: double instead of single item

Re: ceph versions

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

Hi Sage,

I prefer Option D because it's self explanatory. We could also drop the names. I became attached to them but they are confusing to the new users who is required to remember that firefly is 0.80, giant is 0.87 etc.

Cheers

On 27/02/2015 00:12, Sage Weil wrote:
> -- Option D -- "labeled"
> 
> X.Y-{dev,rc,release}Z
> 
>  - Increment Y on each major named release
>  - Increment X if it's a major major named release (bigger change 
> than usual)
>  - Use dev, rc, or release prefix to clearly label what type of release 
> this is
>  - Increment Z for stable updates
> 
>  1.0-dev1 first infernalis dev release
>  1.0-dev2 another dev release
>  ...
>  1.0-rc1 first rc
>  1.0-rc2 next rc
>  1.0-release1 final release
>  1.0-release2 stable update
>  1.0-release3 stable update
>  1.1-dev1 first cut for j-release
>  1.1-dev2 ...
>  ...
>  1.1-rc1
>  1.1-release1 stable
>  1.1-release2 stable
>  1.1-release3 stable
> 
> Q: How do I tell what kind of release this is?
> A: Look at the string embedded in the version
> 
> Q: Will these funny strings confuse things that sort by version?
> A: I don't think so.

dev < rc < release : good pick ;-)

Cheers


-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ceph versions

[Yehuda Sadeh-Weinraub]

----- Original Message -----
> From: "Loic Dachary" <loic@dachary.org>
> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
> Sent: Thursday, February 26, 2015 3:38:31 PM
> Subject: Re: ceph versions
> 
> Hi Sage,
> 
> I prefer Option D because it's self explanatory. We could also drop the
> names. I became attached to them but they are confusing to the new users who
> is required to remember that firefly is 0.80, giant is 0.87 etc.
> 
> Cheers
> 
> On 27/02/2015 00:12, Sage Weil wrote:
> > -- Option D -- "labeled"
> > 
> > X.Y-{dev,rc,release}Z
> > 
> >  - Increment Y on each major named release
> >  - Increment X if it's a major major named release (bigger change
> > than usual)
> >  - Use dev, rc, or release prefix to clearly label what type of release
> > this is
> >  - Increment Z for stable updates
> > 
> >  1.0-dev1 first infernalis dev release
> >  1.0-dev2 another dev release
> >  ...
> >  1.0-rc1 first rc
> >  1.0-rc2 next rc
> >  1.0-release1 final release
> >  1.0-release2 stable update
> >  1.0-release3 stable update
> >  1.1-dev1 first cut for j-release
> >  1.1-dev2 ...
> >  ...
> >  1.1-rc1
> >  1.1-release1 stable
> >  1.1-release2 stable
> >  1.1-release3 stable
> > 
> > Q: How do I tell what kind of release this is?
> > A: Look at the string embedded in the version
> > 
> > Q: Will these funny strings confuse things that sort by version?
> > A: I don't think so.
> 
> dev < rc < release : good pick ;-)
> 

This is the one I lean towards, with one slight variation. I'd drop the 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
2.0-dev1 first infernalis dev release
2.0-dev2
..
2.0-rc1
2.0-rc2
...
2.0 # infarnalis
2.0.1 # first dot release
...
2.1-dev1 # first j dev release
...
2.1 # j release

Then after a few release move to 3.0 to avoid the dreadful big numbers.

Sage did mention that this might have some issues in certain environments to sort correctly. Possibly replacing the dash with a tilde solves this?

Yehuda

Re: ceph versions

[Alex Elsayed]

Yehuda Sadeh-Weinraub wrote:

> 
> 
> ----- Original Message -----
>> From: "Loic Dachary" <loic@dachary.org>
>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>> Sent: Thursday, February 26, 2015 3:38:31 PM
>> Subject: Re: ceph versions
>> 
>> Hi Sage,
>> 
>> I prefer Option D because it's self explanatory. We could also drop the
>> names. I became attached to them but they are confusing to the new users
>> who is required to remember that firefly is 0.80, giant is 0.87 etc.
>> 
>> Cheers
>> 
>> On 27/02/2015 00:12, Sage Weil wrote:
>> > -- Option D -- "labeled"
>> > 
>> > X.Y-{dev,rc,release}Z
>> > 
>> >  - Increment Y on each major named release
>> >  - Increment X if it's a major major named release (bigger change
>> > than usual)
>> >  - Use dev, rc, or release prefix to clearly label what type of release
>> > this is
>> >  - Increment Z for stable updates
>> > 
>> >  1.0-dev1 first infernalis dev release
>> >  1.0-dev2 another dev release
>> >  ...
>> >  1.0-rc1 first rc
>> >  1.0-rc2 next rc
>> >  1.0-release1 final release
>> >  1.0-release2 stable update
>> >  1.0-release3 stable update
>> >  1.1-dev1 first cut for j-release
>> >  1.1-dev2 ...
>> >  ...
>> >  1.1-rc1
>> >  1.1-release1 stable
>> >  1.1-release2 stable
>> >  1.1-release3 stable
>> > 
>> > Q: How do I tell what kind of release this is?
>> > A: Look at the string embedded in the version
>> > 
>> > Q: Will these funny strings confuse things that sort by version?
>> > A: I don't think so.
>> 
>> dev < rc < release : good pick ;-)
>> 
> 
> This is the one I lean towards, with one slight variation. I'd drop the
> 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
> 2.0-dev1 first infernalis dev release 2.0-dev2
> ..
> 2.0-rc1
> 2.0-rc2
> ...
> 2.0 # infarnalis
> 2.0.1 # first dot release
> ...
> 2.1-dev1 # first j dev release
> ...
> 2.1 # j release
> 
> Then after a few release move to 3.0 to avoid the dreadful big numbers.
> 
> Sage did mention that this might have some issues in certain environments
> to sort correctly. Possibly replacing the dash with a tilde solves this?

Sorting correctly isn't the issue - the issue is that you either need 
separate "channels" (which from experience has been a real pain with 
packaging Chrome in Exherbo), or you need to manually rewrite the download 
URL and such because it's an outright invalid version string from the 
package manager's perspective.

Re: ceph versions

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]



On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
> 
> 
> ----- Original Message -----
>> From: "Loic Dachary" <loic@dachary.org>
>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>> Sent: Thursday, February 26, 2015 3:38:31 PM
>> Subject: Re: ceph versions
>>
>> Hi Sage,
>>
>> I prefer Option D because it's self explanatory. We could also drop the
>> names. I became attached to them but they are confusing to the new users who
>> is required to remember that firefly is 0.80, giant is 0.87 etc.
>>
>> Cheers
>>
>> On 27/02/2015 00:12, Sage Weil wrote:
>>> -- Option D -- "labeled"
>>>
>>> X.Y-{dev,rc,release}Z
>>>
>>>  - Increment Y on each major named release
>>>  - Increment X if it's a major major named release (bigger change
>>> than usual)
>>>  - Use dev, rc, or release prefix to clearly label what type of release
>>> this is
>>>  - Increment Z for stable updates
>>>
>>>  1.0-dev1 first infernalis dev release
>>>  1.0-dev2 another dev release
>>>  ...
>>>  1.0-rc1 first rc
>>>  1.0-rc2 next rc
>>>  1.0-release1 final release
>>>  1.0-release2 stable update
>>>  1.0-release3 stable update
>>>  1.1-dev1 first cut for j-release
>>>  1.1-dev2 ...
>>>  ...
>>>  1.1-rc1
>>>  1.1-release1 stable
>>>  1.1-release2 stable
>>>  1.1-release3 stable
>>>
>>> Q: How do I tell what kind of release this is?
>>> A: Look at the string embedded in the version
>>>
>>> Q: Will these funny strings confuse things that sort by version?
>>> A: I don't think so.
>>
>> dev < rc < release : good pick ;-)
>>
> 
> This is the one I lean towards, with one slight variation. I'd drop the 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
> 2.0-dev1 first infernalis dev release
> 2.0-dev2
> ..
> 2.0-rc1
> 2.0-rc2
> ...
> 2.0 # infarnalis
> 2.0.1 # first dot release
> ...
> 2.1-dev1 # first j dev release
> ...
> 2.1 # j release
> 
> Then after a few release move to 3.0 to avoid the dreadful big numbers.
> 
> Sage did mention that this might have some issues in certain environments to sort correctly. Possibly replacing the dash with a tilde solves this?
> 

The lexicographic order of ~ is modified in debian and that may create confusion:

http://man.he.net/man5/deb-version

       lexical comparison is a comparison of ASCII values modified so that all
       the letters sort earlier than all the non-letters and so that  a  tilde
       sorts  before  anything, even the end of a part.  For example, the fol-
       lowing parts are in sorted order: '~~', '~~a',  '~',  the  empty  part,
       'a'.

The - is lower than the . so it should be good provided the major releases are X.Y.0 instead of X.Y, i.e.:

2.0-rc3
2.0.0 # infarnalis
2.0.1 # first dot release

etc.

Dropping the "release" word for stable releases is a good idea.

Cheers

> Yehuda
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ceph versions

[Ilya Dryomov]

On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary <loic@dachary.org> wrote:
>
>
> On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Loic Dachary" <loic@dachary.org>
>>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>>> Sent: Thursday, February 26, 2015 3:38:31 PM
>>> Subject: Re: ceph versions
>>>
>>> Hi Sage,
>>>
>>> I prefer Option D because it's self explanatory. We could also drop the
>>> names. I became attached to them but they are confusing to the new users who
>>> is required to remember that firefly is 0.80, giant is 0.87 etc.
>>>
>>> Cheers
>>>
>>> On 27/02/2015 00:12, Sage Weil wrote:
>>>> -- Option D -- "labeled"
>>>>
>>>> X.Y-{dev,rc,release}Z
>>>>
>>>>  - Increment Y on each major named release
>>>>  - Increment X if it's a major major named release (bigger change
>>>> than usual)
>>>>  - Use dev, rc, or release prefix to clearly label what type of release
>>>> this is
>>>>  - Increment Z for stable updates
>>>>
>>>>  1.0-dev1 first infernalis dev release
>>>>  1.0-dev2 another dev release
>>>>  ...
>>>>  1.0-rc1 first rc
>>>>  1.0-rc2 next rc
>>>>  1.0-release1 final release
>>>>  1.0-release2 stable update
>>>>  1.0-release3 stable update
>>>>  1.1-dev1 first cut for j-release
>>>>  1.1-dev2 ...
>>>>  ...
>>>>  1.1-rc1
>>>>  1.1-release1 stable
>>>>  1.1-release2 stable
>>>>  1.1-release3 stable
>>>>
>>>> Q: How do I tell what kind of release this is?
>>>> A: Look at the string embedded in the version
>>>>
>>>> Q: Will these funny strings confuse things that sort by version?
>>>> A: I don't think so.
>>>
>>> dev < rc < release : good pick ;-)
>>>
>>
>> This is the one I lean towards, with one slight variation. I'd drop the 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
>> 2.0-dev1 first infernalis dev release
>> 2.0-dev2
>> ..
>> 2.0-rc1
>> 2.0-rc2
>> ...
>> 2.0 # infarnalis
>> 2.0.1 # first dot release
>> ...
>> 2.1-dev1 # first j dev release
>> ...
>> 2.1 # j release
>>
>> Then after a few release move to 3.0 to avoid the dreadful big numbers.
>>
>> Sage did mention that this might have some issues in certain environments to sort correctly. Possibly replacing the dash with a tilde solves this?
>>
>
> The lexicographic order of ~ is modified in debian and that may create confusion:
>
> http://man.he.net/man5/deb-version
>
>        lexical comparison is a comparison of ASCII values modified so that all
>        the letters sort earlier than all the non-letters and so that  a  tilde
>        sorts  before  anything, even the end of a part.  For example, the fol-
>        lowing parts are in sorted order: '~~', '~~a',  '~',  the  empty  part,
>        'a'.
>
> The - is lower than the . so it should be good provided the major releases are X.Y.0 instead of X.Y, i.e.:
>
> 2.0-rc3
> 2.0.0 # infarnalis
> 2.0.1 # first dot release
>
> etc.
>
> Dropping the "release" word for stable releases is a good idea.

FWIW I'd lean towards "labeled" scheme without the "release" label as
well.  I don't have a strong opinion on X.Y vs X.Y.0 for formal
releases, but I would have probably gone with X.Y - just my 2c.

Thanks,

                Ilya

Re: ceph versions

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 3569 bytes --]



On 27/02/2015 13:59, Ilya Dryomov wrote:
> On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary <loic@dachary.org> wrote:
>>
>>
>> On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Loic Dachary" <loic@dachary.org>
>>>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>>>> Sent: Thursday, February 26, 2015 3:38:31 PM
>>>> Subject: Re: ceph versions
>>>>
>>>> Hi Sage,
>>>>
>>>> I prefer Option D because it's self explanatory. We could also drop the
>>>> names. I became attached to them but they are confusing to the new users who
>>>> is required to remember that firefly is 0.80, giant is 0.87 etc.
>>>>
>>>> Cheers
>>>>
>>>> On 27/02/2015 00:12, Sage Weil wrote:
>>>>> -- Option D -- "labeled"
>>>>>
>>>>> X.Y-{dev,rc,release}Z
>>>>>
>>>>>  - Increment Y on each major named release
>>>>>  - Increment X if it's a major major named release (bigger change
>>>>> than usual)
>>>>>  - Use dev, rc, or release prefix to clearly label what type of release
>>>>> this is
>>>>>  - Increment Z for stable updates
>>>>>
>>>>>  1.0-dev1 first infernalis dev release
>>>>>  1.0-dev2 another dev release
>>>>>  ...
>>>>>  1.0-rc1 first rc
>>>>>  1.0-rc2 next rc
>>>>>  1.0-release1 final release
>>>>>  1.0-release2 stable update
>>>>>  1.0-release3 stable update
>>>>>  1.1-dev1 first cut for j-release
>>>>>  1.1-dev2 ...
>>>>>  ...
>>>>>  1.1-rc1
>>>>>  1.1-release1 stable
>>>>>  1.1-release2 stable
>>>>>  1.1-release3 stable
>>>>>
>>>>> Q: How do I tell what kind of release this is?
>>>>> A: Look at the string embedded in the version
>>>>>
>>>>> Q: Will these funny strings confuse things that sort by version?
>>>>> A: I don't think so.
>>>>
>>>> dev < rc < release : good pick ;-)
>>>>
>>>
>>> This is the one I lean towards, with one slight variation. I'd drop the 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
>>> 2.0-dev1 first infernalis dev release
>>> 2.0-dev2
>>> ..
>>> 2.0-rc1
>>> 2.0-rc2
>>> ...
>>> 2.0 # infarnalis
>>> 2.0.1 # first dot release
>>> ...
>>> 2.1-dev1 # first j dev release
>>> ...
>>> 2.1 # j release
>>>
>>> Then after a few release move to 3.0 to avoid the dreadful big numbers.
>>>
>>> Sage did mention that this might have some issues in certain environments to sort correctly. Possibly replacing the dash with a tilde solves this?
>>>
>>
>> The lexicographic order of ~ is modified in debian and that may create confusion:
>>
>> http://man.he.net/man5/deb-version
>>
>>        lexical comparison is a comparison of ASCII values modified so that all
>>        the letters sort earlier than all the non-letters and so that  a  tilde
>>        sorts  before  anything, even the end of a part.  For example, the fol-
>>        lowing parts are in sorted order: '~~', '~~a',  '~',  the  empty  part,
>>        'a'.
>>
>> The - is lower than the . so it should be good provided the major releases are X.Y.0 instead of X.Y, i.e.:
>>
>> 2.0-rc3
>> 2.0.0 # infarnalis
>> 2.0.1 # first dot release
>>
>> etc.
>>
>> Dropping the "release" word for stable releases is a good idea.
> 
> FWIW I'd lean towards "labeled" scheme without the "release" label as
> well.  I don't have a strong opinion on X.Y vs X.Y.0 for formal
> releases, but I would have probably gone with X.Y - just my 2c.

The problem with X.Y is that it sorts before X.Y-rc3 instead of after.

> 
> Thanks,
> 
>                 Ilya
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ceph versions

[Ilya Dryomov]

On Fri, Feb 27, 2015 at 4:28 PM, Loic Dachary <loic@dachary.org> wrote:
>
>
> On 27/02/2015 13:59, Ilya Dryomov wrote:
>> On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary <loic@dachary.org> wrote:
>>>
>>>
>>> On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Loic Dachary" <loic@dachary.org>
>>>>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>>>>> Sent: Thursday, February 26, 2015 3:38:31 PM
>>>>> Subject: Re: ceph versions
>>>>>
>>>>> Hi Sage,
>>>>>
>>>>> I prefer Option D because it's self explanatory. We could also drop the
>>>>> names. I became attached to them but they are confusing to the new users who
>>>>> is required to remember that firefly is 0.80, giant is 0.87 etc.
>>>>>
>>>>> Cheers
>>>>>
>>>>> On 27/02/2015 00:12, Sage Weil wrote:
>>>>>> -- Option D -- "labeled"
>>>>>>
>>>>>> X.Y-{dev,rc,release}Z
>>>>>>
>>>>>>  - Increment Y on each major named release
>>>>>>  - Increment X if it's a major major named release (bigger change
>>>>>> than usual)
>>>>>>  - Use dev, rc, or release prefix to clearly label what type of release
>>>>>> this is
>>>>>>  - Increment Z for stable updates
>>>>>>
>>>>>>  1.0-dev1 first infernalis dev release
>>>>>>  1.0-dev2 another dev release
>>>>>>  ...
>>>>>>  1.0-rc1 first rc
>>>>>>  1.0-rc2 next rc
>>>>>>  1.0-release1 final release
>>>>>>  1.0-release2 stable update
>>>>>>  1.0-release3 stable update
>>>>>>  1.1-dev1 first cut for j-release
>>>>>>  1.1-dev2 ...
>>>>>>  ...
>>>>>>  1.1-rc1
>>>>>>  1.1-release1 stable
>>>>>>  1.1-release2 stable
>>>>>>  1.1-release3 stable
>>>>>>
>>>>>> Q: How do I tell what kind of release this is?
>>>>>> A: Look at the string embedded in the version
>>>>>>
>>>>>> Q: Will these funny strings confuse things that sort by version?
>>>>>> A: I don't think so.
>>>>>
>>>>> dev < rc < release : good pick ;-)
>>>>>
>>>>
>>>> This is the one I lean towards, with one slight variation. I'd drop the 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
>>>> 2.0-dev1 first infernalis dev release
>>>> 2.0-dev2
>>>> ..
>>>> 2.0-rc1
>>>> 2.0-rc2
>>>> ...
>>>> 2.0 # infarnalis
>>>> 2.0.1 # first dot release
>>>> ...
>>>> 2.1-dev1 # first j dev release
>>>> ...
>>>> 2.1 # j release
>>>>
>>>> Then after a few release move to 3.0 to avoid the dreadful big numbers.
>>>>
>>>> Sage did mention that this might have some issues in certain environments to sort correctly. Possibly replacing the dash with a tilde solves this?
>>>>
>>>
>>> The lexicographic order of ~ is modified in debian and that may create confusion:
>>>
>>> http://man.he.net/man5/deb-version
>>>
>>>        lexical comparison is a comparison of ASCII values modified so that all
>>>        the letters sort earlier than all the non-letters and so that  a  tilde
>>>        sorts  before  anything, even the end of a part.  For example, the fol-
>>>        lowing parts are in sorted order: '~~', '~~a',  '~',  the  empty  part,
>>>        'a'.
>>>
>>> The - is lower than the . so it should be good provided the major releases are X.Y.0 instead of X.Y, i.e.:
>>>
>>> 2.0-rc3
>>> 2.0.0 # infarnalis
>>> 2.0.1 # first dot release
>>>
>>> etc.
>>>
>>> Dropping the "release" word for stable releases is a good idea.
>>
>> FWIW I'd lean towards "labeled" scheme without the "release" label as
>> well.  I don't have a strong opinion on X.Y vs X.Y.0 for formal
>> releases, but I would have probably gone with X.Y - just my 2c.
>
> The problem with X.Y is that it sorts before X.Y-rc3 instead of after.

Yeah, I guess I just got used to it in linux.git.  But it also makes
formal releases stand out and is easier to refer to.  Sorting tags is
not something you do *that* often.

Thanks,

                Ilya

Re: ceph versions

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 4480 bytes --]



On 27/02/2015 14:49, Ilya Dryomov wrote:
> On Fri, Feb 27, 2015 at 4:28 PM, Loic Dachary <loic@dachary.org> wrote:
>>
>>
>> On 27/02/2015 13:59, Ilya Dryomov wrote:
>>> On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary <loic@dachary.org> wrote:
>>>>
>>>>
>>>> On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Loic Dachary" <loic@dachary.org>
>>>>>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>>>>>> Sent: Thursday, February 26, 2015 3:38:31 PM
>>>>>> Subject: Re: ceph versions
>>>>>>
>>>>>> Hi Sage,
>>>>>>
>>>>>> I prefer Option D because it's self explanatory. We could also drop the
>>>>>> names. I became attached to them but they are confusing to the new users who
>>>>>> is required to remember that firefly is 0.80, giant is 0.87 etc.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> On 27/02/2015 00:12, Sage Weil wrote:
>>>>>>> -- Option D -- "labeled"
>>>>>>>
>>>>>>> X.Y-{dev,rc,release}Z
>>>>>>>
>>>>>>>  - Increment Y on each major named release
>>>>>>>  - Increment X if it's a major major named release (bigger change
>>>>>>> than usual)
>>>>>>>  - Use dev, rc, or release prefix to clearly label what type of release
>>>>>>> this is
>>>>>>>  - Increment Z for stable updates
>>>>>>>
>>>>>>>  1.0-dev1 first infernalis dev release
>>>>>>>  1.0-dev2 another dev release
>>>>>>>  ...
>>>>>>>  1.0-rc1 first rc
>>>>>>>  1.0-rc2 next rc
>>>>>>>  1.0-release1 final release
>>>>>>>  1.0-release2 stable update
>>>>>>>  1.0-release3 stable update
>>>>>>>  1.1-dev1 first cut for j-release
>>>>>>>  1.1-dev2 ...
>>>>>>>  ...
>>>>>>>  1.1-rc1
>>>>>>>  1.1-release1 stable
>>>>>>>  1.1-release2 stable
>>>>>>>  1.1-release3 stable
>>>>>>>
>>>>>>> Q: How do I tell what kind of release this is?
>>>>>>> A: Look at the string embedded in the version
>>>>>>>
>>>>>>> Q: Will these funny strings confuse things that sort by version?
>>>>>>> A: I don't think so.
>>>>>>
>>>>>> dev < rc < release : good pick ;-)
>>>>>>
>>>>>
>>>>> This is the one I lean towards, with one slight variation. I'd drop the 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
>>>>> 2.0-dev1 first infernalis dev release
>>>>> 2.0-dev2
>>>>> ..
>>>>> 2.0-rc1
>>>>> 2.0-rc2
>>>>> ...
>>>>> 2.0 # infarnalis
>>>>> 2.0.1 # first dot release
>>>>> ...
>>>>> 2.1-dev1 # first j dev release
>>>>> ...
>>>>> 2.1 # j release
>>>>>
>>>>> Then after a few release move to 3.0 to avoid the dreadful big numbers.
>>>>>
>>>>> Sage did mention that this might have some issues in certain environments to sort correctly. Possibly replacing the dash with a tilde solves this?
>>>>>
>>>>
>>>> The lexicographic order of ~ is modified in debian and that may create confusion:
>>>>
>>>> http://man.he.net/man5/deb-version
>>>>
>>>>        lexical comparison is a comparison of ASCII values modified so that all
>>>>        the letters sort earlier than all the non-letters and so that  a  tilde
>>>>        sorts  before  anything, even the end of a part.  For example, the fol-
>>>>        lowing parts are in sorted order: '~~', '~~a',  '~',  the  empty  part,
>>>>        'a'.
>>>>
>>>> The - is lower than the . so it should be good provided the major releases are X.Y.0 instead of X.Y, i.e.:
>>>>
>>>> 2.0-rc3
>>>> 2.0.0 # infarnalis
>>>> 2.0.1 # first dot release
>>>>
>>>> etc.
>>>>
>>>> Dropping the "release" word for stable releases is a good idea.
>>>
>>> FWIW I'd lean towards "labeled" scheme without the "release" label as
>>> well.  I don't have a strong opinion on X.Y vs X.Y.0 for formal
>>> releases, but I would have probably gone with X.Y - just my 2c.
>>
>> The problem with X.Y is that it sorts before X.Y-rc3 instead of after.
> 
> Yeah, I guess I just got used to it in linux.git.  But it also makes
> formal releases stand out and is easier to refer to.  Sorting tags is
> not something you do *that* often.

Assuming a script creates the version of the debian package based on the tag, I guess it matters in that context. Not sure how linux kernel packages in debian deal with that.

Cheers

> 
> Thanks,
> 
>                 Ilya
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ceph versions

[Yehuda Sadeh-Weinraub]

----- Original Message -----
> From: "Loic Dachary" <loic@dachary.org>
> To: "Ilya Dryomov" <idryomov@gmail.com>
> Cc: "Yehuda Sadeh-Weinraub" <yehuda@redhat.com>, "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
> Sent: Friday, February 27, 2015 5:55:32 AM
> Subject: Re: ceph versions
> 
> 
> 
> On 27/02/2015 14:49, Ilya Dryomov wrote:
> > On Fri, Feb 27, 2015 at 4:28 PM, Loic Dachary <loic@dachary.org> wrote:
> >>
> >>
> >> On 27/02/2015 13:59, Ilya Dryomov wrote:
> >>> On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary <loic@dachary.org> wrote:
> >>>>
> >>>>
> >>>> On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Loic Dachary" <loic@dachary.org>
> >>>>>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
> >>>>>> Sent: Thursday, February 26, 2015 3:38:31 PM
> >>>>>> Subject: Re: ceph versions
> >>>>>>
> >>>>>> Hi Sage,
> >>>>>>
> >>>>>> I prefer Option D because it's self explanatory. We could also drop
> >>>>>> the
> >>>>>> names. I became attached to them but they are confusing to the new
> >>>>>> users who
> >>>>>> is required to remember that firefly is 0.80, giant is 0.87 etc.
> >>>>>>
> >>>>>> Cheers
> >>>>>>
> >>>>>> On 27/02/2015 00:12, Sage Weil wrote:
> >>>>>>> -- Option D -- "labeled"
> >>>>>>>
> >>>>>>> X.Y-{dev,rc,release}Z
> >>>>>>>
> >>>>>>>  - Increment Y on each major named release
> >>>>>>>  - Increment X if it's a major major named release (bigger change
> >>>>>>> than usual)
> >>>>>>>  - Use dev, rc, or release prefix to clearly label what type of
> >>>>>>>  release
> >>>>>>> this is
> >>>>>>>  - Increment Z for stable updates
> >>>>>>>
> >>>>>>>  1.0-dev1 first infernalis dev release
> >>>>>>>  1.0-dev2 another dev release
> >>>>>>>  ...
> >>>>>>>  1.0-rc1 first rc
> >>>>>>>  1.0-rc2 next rc
> >>>>>>>  1.0-release1 final release
> >>>>>>>  1.0-release2 stable update
> >>>>>>>  1.0-release3 stable update
> >>>>>>>  1.1-dev1 first cut for j-release
> >>>>>>>  1.1-dev2 ...
> >>>>>>>  ...
> >>>>>>>  1.1-rc1
> >>>>>>>  1.1-release1 stable
> >>>>>>>  1.1-release2 stable
> >>>>>>>  1.1-release3 stable
> >>>>>>>
> >>>>>>> Q: How do I tell what kind of release this is?
> >>>>>>> A: Look at the string embedded in the version
> >>>>>>>
> >>>>>>> Q: Will these funny strings confuse things that sort by version?
> >>>>>>> A: I don't think so.
> >>>>>>
> >>>>>> dev < rc < release : good pick ;-)
> >>>>>>
> >>>>>
> >>>>> This is the one I lean towards, with one slight variation. I'd drop the
> >>>>> 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
> >>>>> 2.0-dev1 first infernalis dev release
> >>>>> 2.0-dev2
> >>>>> ..
> >>>>> 2.0-rc1
> >>>>> 2.0-rc2
> >>>>> ...
> >>>>> 2.0 # infarnalis
> >>>>> 2.0.1 # first dot release
> >>>>> ...
> >>>>> 2.1-dev1 # first j dev release
> >>>>> ...
> >>>>> 2.1 # j release
> >>>>>
> >>>>> Then after a few release move to 3.0 to avoid the dreadful big numbers.
> >>>>>
> >>>>> Sage did mention that this might have some issues in certain
> >>>>> environments to sort correctly. Possibly replacing the dash with a
> >>>>> tilde solves this?
> >>>>>
> >>>>
> >>>> The lexicographic order of ~ is modified in debian and that may create
> >>>> confusion:
> >>>>
> >>>> http://man.he.net/man5/deb-version
> >>>>
> >>>>        lexical comparison is a comparison of ASCII values modified so
> >>>>        that all
> >>>>        the letters sort earlier than all the non-letters and so that  a
> >>>>        tilde
> >>>>        sorts  before  anything, even the end of a part.  For example,
> >>>>        the fol-
> >>>>        lowing parts are in sorted order: '~~', '~~a',  '~',  the  empty
> >>>>        part,
> >>>>        'a'.
> >>>>
> >>>> The - is lower than the . so it should be good provided the major
> >>>> releases are X.Y.0 instead of X.Y, i.e.:
> >>>>
> >>>> 2.0-rc3
> >>>> 2.0.0 # infarnalis
> >>>> 2.0.1 # first dot release
> >>>>
> >>>> etc.
> >>>>
> >>>> Dropping the "release" word for stable releases is a good idea.
> >>>
> >>> FWIW I'd lean towards "labeled" scheme without the "release" label as
> >>> well.  I don't have a strong opinion on X.Y vs X.Y.0 for formal
> >>> releases, but I would have probably gone with X.Y - just my 2c.
> >>
> >> The problem with X.Y is that it sorts before X.Y-rc3 instead of after.
> > 
> > Yeah, I guess I just got used to it in linux.git.  But it also makes
> > formal releases stand out and is easier to refer to.  Sorting tags is
> > not something you do *that* often.
> 
> Assuming a script creates the version of the debian package based on the tag,
> I guess it matters in that context. Not sure how linux kernel packages in
> debian deal with that.
> 

btw, what if it'd be like this:

2.0dev1
2.0dev2
...
2.0rc1
...
2.0
2.0.1

Will we have that issue when the label is attached directly without a dot, or maybe the package managers handle it differently? I seem to vaguely remember something like that but I might be completely wrong. 

Yehuda

Re: ceph versions

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 5564 bytes --]



On 27/02/2015 17:29, Yehuda Sadeh-Weinraub wrote:
> 
> 
> ----- Original Message -----
>> From: "Loic Dachary" <loic@dachary.org>
>> To: "Ilya Dryomov" <idryomov@gmail.com>
>> Cc: "Yehuda Sadeh-Weinraub" <yehuda@redhat.com>, "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>> Sent: Friday, February 27, 2015 5:55:32 AM
>> Subject: Re: ceph versions
>>
>>
>>
>> On 27/02/2015 14:49, Ilya Dryomov wrote:
>>> On Fri, Feb 27, 2015 at 4:28 PM, Loic Dachary <loic@dachary.org> wrote:
>>>>
>>>>
>>>> On 27/02/2015 13:59, Ilya Dryomov wrote:
>>>>> On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary <loic@dachary.org> wrote:
>>>>>>
>>>>>>
>>>>>> On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Loic Dachary" <loic@dachary.org>
>>>>>>>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>>>>>>>> Sent: Thursday, February 26, 2015 3:38:31 PM
>>>>>>>> Subject: Re: ceph versions
>>>>>>>>
>>>>>>>> Hi Sage,
>>>>>>>>
>>>>>>>> I prefer Option D because it's self explanatory. We could also drop
>>>>>>>> the
>>>>>>>> names. I became attached to them but they are confusing to the new
>>>>>>>> users who
>>>>>>>> is required to remember that firefly is 0.80, giant is 0.87 etc.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>> On 27/02/2015 00:12, Sage Weil wrote:
>>>>>>>>> -- Option D -- "labeled"
>>>>>>>>>
>>>>>>>>> X.Y-{dev,rc,release}Z
>>>>>>>>>
>>>>>>>>>  - Increment Y on each major named release
>>>>>>>>>  - Increment X if it's a major major named release (bigger change
>>>>>>>>> than usual)
>>>>>>>>>  - Use dev, rc, or release prefix to clearly label what type of
>>>>>>>>>  release
>>>>>>>>> this is
>>>>>>>>>  - Increment Z for stable updates
>>>>>>>>>
>>>>>>>>>  1.0-dev1 first infernalis dev release
>>>>>>>>>  1.0-dev2 another dev release
>>>>>>>>>  ...
>>>>>>>>>  1.0-rc1 first rc
>>>>>>>>>  1.0-rc2 next rc
>>>>>>>>>  1.0-release1 final release
>>>>>>>>>  1.0-release2 stable update
>>>>>>>>>  1.0-release3 stable update
>>>>>>>>>  1.1-dev1 first cut for j-release
>>>>>>>>>  1.1-dev2 ...
>>>>>>>>>  ...
>>>>>>>>>  1.1-rc1
>>>>>>>>>  1.1-release1 stable
>>>>>>>>>  1.1-release2 stable
>>>>>>>>>  1.1-release3 stable
>>>>>>>>>
>>>>>>>>> Q: How do I tell what kind of release this is?
>>>>>>>>> A: Look at the string embedded in the version
>>>>>>>>>
>>>>>>>>> Q: Will these funny strings confuse things that sort by version?
>>>>>>>>> A: I don't think so.
>>>>>>>>
>>>>>>>> dev < rc < release : good pick ;-)
>>>>>>>>
>>>>>>>
>>>>>>> This is the one I lean towards, with one slight variation. I'd drop the
>>>>>>> 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
>>>>>>> 2.0-dev1 first infernalis dev release
>>>>>>> 2.0-dev2
>>>>>>> ..
>>>>>>> 2.0-rc1
>>>>>>> 2.0-rc2
>>>>>>> ...
>>>>>>> 2.0 # infarnalis
>>>>>>> 2.0.1 # first dot release
>>>>>>> ...
>>>>>>> 2.1-dev1 # first j dev release
>>>>>>> ...
>>>>>>> 2.1 # j release
>>>>>>>
>>>>>>> Then after a few release move to 3.0 to avoid the dreadful big numbers.
>>>>>>>
>>>>>>> Sage did mention that this might have some issues in certain
>>>>>>> environments to sort correctly. Possibly replacing the dash with a
>>>>>>> tilde solves this?
>>>>>>>
>>>>>>
>>>>>> The lexicographic order of ~ is modified in debian and that may create
>>>>>> confusion:
>>>>>>
>>>>>> http://man.he.net/man5/deb-version
>>>>>>
>>>>>>        lexical comparison is a comparison of ASCII values modified so
>>>>>>        that all
>>>>>>        the letters sort earlier than all the non-letters and so that  a
>>>>>>        tilde
>>>>>>        sorts  before  anything, even the end of a part.  For example,
>>>>>>        the fol-
>>>>>>        lowing parts are in sorted order: '~~', '~~a',  '~',  the  empty
>>>>>>        part,
>>>>>>        'a'.
>>>>>>
>>>>>> The - is lower than the . so it should be good provided the major
>>>>>> releases are X.Y.0 instead of X.Y, i.e.:
>>>>>>
>>>>>> 2.0-rc3
>>>>>> 2.0.0 # infarnalis
>>>>>> 2.0.1 # first dot release
>>>>>>
>>>>>> etc.
>>>>>>
>>>>>> Dropping the "release" word for stable releases is a good idea.
>>>>>
>>>>> FWIW I'd lean towards "labeled" scheme without the "release" label as
>>>>> well.  I don't have a strong opinion on X.Y vs X.Y.0 for formal
>>>>> releases, but I would have probably gone with X.Y - just my 2c.
>>>>
>>>> The problem with X.Y is that it sorts before X.Y-rc3 instead of after.
>>>
>>> Yeah, I guess I just got used to it in linux.git.  But it also makes
>>> formal releases stand out and is easier to refer to.  Sorting tags is
>>> not something you do *that* often.
>>
>> Assuming a script creates the version of the debian package based on the tag,
>> I guess it matters in that context. Not sure how linux kernel packages in
>> debian deal with that.
>>
> 
> btw, what if it'd be like this:
> 
> 2.0dev1
> 2.0dev2
> ...
> 2.0rc1
> ...
> 2.0
> 2.0.1
> 
> Will we have that issue when the label is attached directly without a dot, or maybe the package managers handle it differently? I seem to vaguely remember something like that but I might be completely wrong. 

That still leaves us with 2.0 sorted before 2.0dev1

> Yehuda
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ceph versions

[Alex Elsayed]

Loic Dachary wrote:

> 
> 
> On 27/02/2015 13:59, Ilya Dryomov wrote:
>> On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary <loic@dachary.org> wrote:
>>>
>>>
>>> On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Loic Dachary" <loic@dachary.org>
>>>>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>>>>> Sent: Thursday, February 26, 2015 3:38:31 PM
>>>>> Subject: Re: ceph versions
>>>>>
>>>>> Hi Sage,
>>>>>
>>>>> I prefer Option D because it's self explanatory. We could also drop
>>>>> the names. I became attached to them but they are confusing to the new
>>>>> users who is required to remember that firefly is 0.80, giant is 0.87
>>>>> etc.
>>>>>
>>>>> Cheers
>>>>>
>>>>> On 27/02/2015 00:12, Sage Weil wrote:
>>>>>> -- Option D -- "labeled"
>>>>>>
>>>>>> X.Y-{dev,rc,release}Z
>>>>>>
>>>>>>  - Increment Y on each major named release
>>>>>>  - Increment X if it's a major major named release (bigger change
>>>>>> than usual)
>>>>>>  - Use dev, rc, or release prefix to clearly label what type of
>>>>>>  release
>>>>>> this is
>>>>>>  - Increment Z for stable updates
>>>>>>
>>>>>>  1.0-dev1 first infernalis dev release
>>>>>>  1.0-dev2 another dev release
>>>>>>  ...
>>>>>>  1.0-rc1 first rc
>>>>>>  1.0-rc2 next rc
>>>>>>  1.0-release1 final release
>>>>>>  1.0-release2 stable update
>>>>>>  1.0-release3 stable update
>>>>>>  1.1-dev1 first cut for j-release
>>>>>>  1.1-dev2 ...
>>>>>>  ...
>>>>>>  1.1-rc1
>>>>>>  1.1-release1 stable
>>>>>>  1.1-release2 stable
>>>>>>  1.1-release3 stable
>>>>>>
>>>>>> Q: How do I tell what kind of release this is?
>>>>>> A: Look at the string embedded in the version
>>>>>>
>>>>>> Q: Will these funny strings confuse things that sort by version?
>>>>>> A: I don't think so.
>>>>>
>>>>> dev < rc < release : good pick ;-)
>>>>>
>>>>
>>>> This is the one I lean towards, with one slight variation. I'd drop the
>>>> 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
>>>> 2.0-dev1 first infernalis dev release 2.0-dev2
>>>> ..
>>>> 2.0-rc1
>>>> 2.0-rc2
>>>> ...
>>>> 2.0 # infarnalis
>>>> 2.0.1 # first dot release
>>>> ...
>>>> 2.1-dev1 # first j dev release
>>>> ...
>>>> 2.1 # j release
>>>>
>>>> Then after a few release move to 3.0 to avoid the dreadful big numbers.
>>>>
>>>> Sage did mention that this might have some issues in certain
>>>> environments to sort correctly. Possibly replacing the dash with a
>>>> tilde solves this?
>>>>
>>>
>>> The lexicographic order of ~ is modified in debian and that may create
>>> confusion:
>>>
>>> http://man.he.net/man5/deb-version
>>>
>>>        lexical comparison is a comparison of ASCII values modified so
>>>        that all
>>>        the letters sort earlier than all the non-letters and so that  a 
>>>        tilde
>>>        sorts  before  anything, even the end of a part.  For example,
>>>        the fol-
>>>        lowing parts are in sorted order: '~~', '~~a',  '~',  the  empty 
>>>        part, 'a'.
>>>
>>> The - is lower than the . so it should be good provided the major
>>> releases are X.Y.0 instead of X.Y, i.e.:
>>>
>>> 2.0-rc3
>>> 2.0.0 # infarnalis
>>> 2.0.1 # first dot release
>>>
>>> etc.
>>>
>>> Dropping the "release" word for stable releases is a good idea.
>> 
>> FWIW I'd lean towards "labeled" scheme without the "release" label as
>> well.  I don't have a strong opinion on X.Y vs X.Y.0 for formal
>> releases, but I would have probably gone with X.Y - just my 2c.
> 
> The problem with X.Y is that it sorts before X.Y-rc3 instead of after.

Stringwise, yes - though in Exherbo and Gentoo, X.Y-rc3 sorts before X.Y 
because not all distros treat versions as strings.

Re: ceph versions

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 4355 bytes --]



On 27/02/2015 23:47, Alex Elsayed wrote:
> Loic Dachary wrote:
> 
>>
>>
>> On 27/02/2015 13:59, Ilya Dryomov wrote:
>>> On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary <loic@dachary.org> wrote:
>>>>
>>>>
>>>> On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Loic Dachary" <loic@dachary.org>
>>>>>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>>>>>> Sent: Thursday, February 26, 2015 3:38:31 PM
>>>>>> Subject: Re: ceph versions
>>>>>>
>>>>>> Hi Sage,
>>>>>>
>>>>>> I prefer Option D because it's self explanatory. We could also drop
>>>>>> the names. I became attached to them but they are confusing to the new
>>>>>> users who is required to remember that firefly is 0.80, giant is 0.87
>>>>>> etc.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> On 27/02/2015 00:12, Sage Weil wrote:
>>>>>>> -- Option D -- "labeled"
>>>>>>>
>>>>>>> X.Y-{dev,rc,release}Z
>>>>>>>
>>>>>>>  - Increment Y on each major named release
>>>>>>>  - Increment X if it's a major major named release (bigger change
>>>>>>> than usual)
>>>>>>>  - Use dev, rc, or release prefix to clearly label what type of
>>>>>>>  release
>>>>>>> this is
>>>>>>>  - Increment Z for stable updates
>>>>>>>
>>>>>>>  1.0-dev1 first infernalis dev release
>>>>>>>  1.0-dev2 another dev release
>>>>>>>  ...
>>>>>>>  1.0-rc1 first rc
>>>>>>>  1.0-rc2 next rc
>>>>>>>  1.0-release1 final release
>>>>>>>  1.0-release2 stable update
>>>>>>>  1.0-release3 stable update
>>>>>>>  1.1-dev1 first cut for j-release
>>>>>>>  1.1-dev2 ...
>>>>>>>  ...
>>>>>>>  1.1-rc1
>>>>>>>  1.1-release1 stable
>>>>>>>  1.1-release2 stable
>>>>>>>  1.1-release3 stable
>>>>>>>
>>>>>>> Q: How do I tell what kind of release this is?
>>>>>>> A: Look at the string embedded in the version
>>>>>>>
>>>>>>> Q: Will these funny strings confuse things that sort by version?
>>>>>>> A: I don't think so.
>>>>>>
>>>>>> dev < rc < release : good pick ;-)
>>>>>>
>>>>>
>>>>> This is the one I lean towards, with one slight variation. I'd drop the
>>>>> 'release' tag and have X.Y[.Z] format for the formal releases, e.g.,
>>>>> 2.0-dev1 first infernalis dev release 2.0-dev2
>>>>> ..
>>>>> 2.0-rc1
>>>>> 2.0-rc2
>>>>> ...
>>>>> 2.0 # infarnalis
>>>>> 2.0.1 # first dot release
>>>>> ...
>>>>> 2.1-dev1 # first j dev release
>>>>> ...
>>>>> 2.1 # j release
>>>>>
>>>>> Then after a few release move to 3.0 to avoid the dreadful big numbers.
>>>>>
>>>>> Sage did mention that this might have some issues in certain
>>>>> environments to sort correctly. Possibly replacing the dash with a
>>>>> tilde solves this?
>>>>>
>>>>
>>>> The lexicographic order of ~ is modified in debian and that may create
>>>> confusion:
>>>>
>>>> http://man.he.net/man5/deb-version
>>>>
>>>>        lexical comparison is a comparison of ASCII values modified so
>>>>        that all
>>>>        the letters sort earlier than all the non-letters and so that  a 
>>>>        tilde
>>>>        sorts  before  anything, even the end of a part.  For example,
>>>>        the fol-
>>>>        lowing parts are in sorted order: '~~', '~~a',  '~',  the  empty 
>>>>        part, 'a'.
>>>>
>>>> The - is lower than the . so it should be good provided the major
>>>> releases are X.Y.0 instead of X.Y, i.e.:
>>>>
>>>> 2.0-rc3
>>>> 2.0.0 # infarnalis
>>>> 2.0.1 # first dot release
>>>>
>>>> etc.
>>>>
>>>> Dropping the "release" word for stable releases is a good idea.
>>>
>>> FWIW I'd lean towards "labeled" scheme without the "release" label as
>>> well.  I don't have a strong opinion on X.Y vs X.Y.0 for formal
>>> releases, but I would have probably gone with X.Y - just my 2c.
>>
>> The problem with X.Y is that it sorts before X.Y-rc3 instead of after.
> 
> Stringwise, yes - though in Exherbo and Gentoo, X.Y-rc3 sorts before X.Y 
> because not all distros treat versions as strings.

Interesting :-) Using X.Y.0 for the first stable release sorts the same, numerically or lexicographically, right ?
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ceph versions

[Alex Elsayed]

Loic Dachary wrote:

> 
> 
> On 27/02/2015 23:47, Alex Elsayed wrote:
>> Loic Dachary wrote:
>> 
>>>
>>>
>>> On 27/02/2015 13:59, Ilya Dryomov wrote:
>>>> On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary <loic@dachary.org> wrote:
>>>>>
>>>>>
>>>>> On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Loic Dachary" <loic@dachary.org>
>>>>>>> To: "Sage Weil" <sweil@redhat.com>, ceph-devel@vger.kernel.org
>>>>>>> Sent: Thursday, February 26, 2015 3:38:31 PM
>>>>>>> Subject: Re: ceph versions
>>>>>>>
>>>>>>> Hi Sage,
>>>>>>>
>>>>>>> I prefer Option D because it's self explanatory. We could also drop
>>>>>>> the names. I became attached to them but they are confusing to the
>>>>>>> new users who is required to remember that firefly is 0.80, giant is
>>>>>>> 0.87 etc.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> On 27/02/2015 00:12, Sage Weil wrote:
>>>>>>>> -- Option D -- "labeled"
>>>>>>>>
>>>>>>>> X.Y-{dev,rc,release}Z
>>>>>>>>
>>>>>>>>  - Increment Y on each major named release
>>>>>>>>  - Increment X if it's a major major named release (bigger change
>>>>>>>> than usual)
>>>>>>>>  - Use dev, rc, or release prefix to clearly label what type of
>>>>>>>>  release
>>>>>>>> this is
>>>>>>>>  - Increment Z for stable updates
>>>>>>>>
>>>>>>>>  1.0-dev1 first infernalis dev release
>>>>>>>>  1.0-dev2 another dev release
>>>>>>>>  ...
>>>>>>>>  1.0-rc1 first rc
>>>>>>>>  1.0-rc2 next rc
>>>>>>>>  1.0-release1 final release
>>>>>>>>  1.0-release2 stable update
>>>>>>>>  1.0-release3 stable update
>>>>>>>>  1.1-dev1 first cut for j-release
>>>>>>>>  1.1-dev2 ...
>>>>>>>>  ...
>>>>>>>>  1.1-rc1
>>>>>>>>  1.1-release1 stable
>>>>>>>>  1.1-release2 stable
>>>>>>>>  1.1-release3 stable
>>>>>>>>
>>>>>>>> Q: How do I tell what kind of release this is?
>>>>>>>> A: Look at the string embedded in the version
>>>>>>>>
>>>>>>>> Q: Will these funny strings confuse things that sort by version?
>>>>>>>> A: I don't think so.
>>>>>>>
>>>>>>> dev < rc < release : good pick ;-)
>>>>>>>
>>>>>>
>>>>>> This is the one I lean towards, with one slight variation. I'd drop
>>>>>> the 'release' tag and have X.Y[.Z] format for the formal releases,
>>>>>> e.g., 2.0-dev1 first infernalis dev release 2.0-dev2
>>>>>> ..
>>>>>> 2.0-rc1
>>>>>> 2.0-rc2
>>>>>> ...
>>>>>> 2.0 # infarnalis
>>>>>> 2.0.1 # first dot release
>>>>>> ...
>>>>>> 2.1-dev1 # first j dev release
>>>>>> ...
>>>>>> 2.1 # j release
>>>>>>
>>>>>> Then after a few release move to 3.0 to avoid the dreadful big
>>>>>> numbers.
>>>>>>
>>>>>> Sage did mention that this might have some issues in certain
>>>>>> environments to sort correctly. Possibly replacing the dash with a
>>>>>> tilde solves this?
>>>>>>
>>>>>
>>>>> The lexicographic order of ~ is modified in debian and that may create
>>>>> confusion:
>>>>>
>>>>> http://man.he.net/man5/deb-version
>>>>>
>>>>>        lexical comparison is a comparison of ASCII values modified so
>>>>>        that all
>>>>>        the letters sort earlier than all the non-letters and so that 
>>>>>        a tilde
>>>>>        sorts  before  anything, even the end of a part.  For example,
>>>>>        the fol-
>>>>>        lowing parts are in sorted order: '~~', '~~a',  '~',  the 
>>>>>        empty part, 'a'.
>>>>>
>>>>> The - is lower than the . so it should be good provided the major
>>>>> releases are X.Y.0 instead of X.Y, i.e.:
>>>>>
>>>>> 2.0-rc3
>>>>> 2.0.0 # infarnalis
>>>>> 2.0.1 # first dot release
>>>>>
>>>>> etc.
>>>>>
>>>>> Dropping the "release" word for stable releases is a good idea.
>>>>
>>>> FWIW I'd lean towards "labeled" scheme without the "release" label as
>>>> well.  I don't have a strong opinion on X.Y vs X.Y.0 for formal
>>>> releases, but I would have probably gone with X.Y - just my 2c.
>>>
>>> The problem with X.Y is that it sorts before X.Y-rc3 instead of after.
>> 
>> Stringwise, yes - though in Exherbo and Gentoo, X.Y-rc3 sorts before X.Y
>> because not all distros treat versions as strings.
> 
> Interesting :-) Using X.Y.0 for the first stable release sorts the same,
> numerically or lexicographically, right ?

On Exherbo and Gentoo, X.Y == X.Y.0 by spec, and if both exist in a single 
repository it's considered a spec violation on the part of the repository.

To be precise, both have explicit understanding of _alpha{int}, _beta{int}, 
_rc{int}, and _pre{int}, in that order of increasing comparison, all less 
than X.Y. Exherbo mildly loosens the rules to allow a hyphen as a separator 
between the version and the tag, while Gentoo does not.

(I might be wrong about where _pre sits; Gentoo has a spec (Package Manager 
Spec or 'PMS') that actually lays it out, along with the full constraints on 
version validity.)

Re: ceph versions

[Alex Elsayed]

Commentary inline.

Note that when I talk about dependencies, I'm speaking as someone who does 
distro packaging - and thus what would require manual changes on the 
packager's part vs. ability to specify general constraints.

Sage Weil wrote:

> Hammer will most likely be v0.94[.x].  We're getting awfully close to
> 0.99, though, which makes many people think 1.0 or 1.00 (isntead of
> 0.100), and the current versioning is getting a bit silly.  So let's talk
> about alternatives!
> 
> Here are a few of options:
> 
> -- Option A -- "doubles and triples"
> 
> X.Y[.Z]
> 
>  - Increment X at the start of each major dev cycle (hammer, infernalis)
>  - Increment Y for each iteration during that cycle
>  - Eventually decide it's good and start adding .Z for the stable fixes.
> 
> For example,
> 
>  1.0 first infernalis dev release
>  1.1 dev release
>  ...
>  1.8 infernalis rc
>  1.9 infernalis final
>  1.9.1 stable update
>  1.9.2 stable update
>  ...
>  2.0 first j (jewel?) dev release
>  2.1 next dev release
>  ...
>  2.8 final j
>  2.8.x stable j releases
> 
> Q: How do I tell if it's a stable release?
> A: It is a triple instead of a double.
> 
> Q: How do I tell if this is the final release in the series?
> A: Nobody knows that until we start doing stable updates; see above.

Pros:
- Linux uses this, so there's some precedent
- Mapping names to numbers is clear

Cons:
- Do we define X.Y.0 as the first stable, or an alias for X.Y?
- Impossible to express the stable/unstable constraint in terms of 
dependencies
- Impossible to express breaking-change constraint in terms of dependencies

> -- Option B -- "even/odd"
> 
> X.Y.Z
> 
>  - if Y is even, this is a stable series
>  - if Y is odd, this is a dev release
>  - increment X when something major happens
> 
>  1.0 hammer final
>  1.0.1 stable/bugfix
>  1.0.2 stable
>  1.0.3 stable
>  ...
>  1.1.0 infernalis dev release
>  1.1.1 infernalis dev release
>  1.1.2 infernalis dev release
>  ...
>  1.2.0 infernalis final
>  1.2.1 stable branch
>  ...
>  1.3.0 j-release dev
>  1.3.1 j-release dev
>  1.3.2 j-release dev
>  ...
>  1.4.0 j-release final
>  1.4.1 stable
>  1.4.1 stable
> 
> Q: How do I tell if it's a stable release?
> A: Second item is even.

Pros:
- Linux used to do this (and the reasons it stopped don't really apply)
- Some other projects still do this
- Mapping names to numbers is clear

Cons:
- Impossible to express the stable/unstable constraint in terms of 
dependencies
- Impossible to express breaking-change constraint in terms of dependencies

> -- Option C -- "semantic"
> 
> major.minor.patch
> 
> - MAJOR version when you make incompatible API changes,
> - MINOR version when you add functionality in a backwards-compatible
> manner, and
> - PATCH version when you make backwards-compatible bug fixes.
> 
>  1.0.0 hammer final
>  1.0.1 bugfix
>  1.0.1 bugfix
>  1.0.1 bugfix
>  1.1 infernalis dev release
>  1.2 infernalis dev release
>  2.0 infernalis dev release
>  2.1 infernalis dev release
>  2.2 infernalis dev release
>  2.3 infernalis final
>  2.3.0 bugfix
>  2.3.1 bugfix
>  2.3.2 bugfix
>  2.4 j dev release
>  ...
>  2.14 j final
>  2.14.0 bugfix
>  2.14.1 bugfix
>  ...
>  2.15 k dev
>  ..
>  3.3 k final
>  3.3.1 bugfix
>  ...
>  
> Q: How do I tell what named release series this is?
> A: As with the others, you just have to know.
> 
> Q: How do we distinguish between stable-series updates and dev updates?
> A: Stable series are triples.
> 
> Q: How do I know if I can downgrade?
> A: The major hasn't changed.
> 
> Q: Really?
> A: Well, maybe.  We haven't dealt with downgrades yet so this assumes we
> get it right (and test it).  We may not realize there is a
> backward-incompatible change right away and only discover it later during
> testing, at which point the versions are fixed; we'd probably bump the
> *next* release in response.

Pros:
- Dependencies can express breaking-change constraints
- Strong adoption in the language-packaging world (Ruby, Node, Rust...)
- Determining whether the major needs bumped could possibly be automated

Cons:
- Mapping names to numbers is nontrivial
- Impossible to express stable/unstable constraint in terms of dependencies
- Requires more developer effort to determine what version to release with

> -- Option D -- "labeled"
> 
> X.Y-{dev,rc,release}Z
> 
>  - Increment Y on each major named release
>  - Increment X if it's a major major named release (bigger change
> than usual)
>  - Use dev, rc, or release prefix to clearly label what type of release
> this is
>  - Increment Z for stable updates
> 
>  1.0-dev1 first infernalis dev release
>  1.0-dev2 another dev release
>  ...
>  1.0-rc1 first rc
>  1.0-rc2 next rc
>  1.0-release1 final release
>  1.0-release2 stable update
>  1.0-release3 stable update
>  1.1-dev1 first cut for j-release
>  1.1-dev2 ...
>  ...
>  1.1-rc1
>  1.1-release1 stable
>  1.1-release2 stable
>  1.1-release3 stable
> 
> Q: How do I tell what kind of release this is?
> A: Look at the string embedded in the version
> 
> Q: Will these funny strings confuse things that sort by version?
> A: I don't think so.

Pros:
- Mapping versions to names is easy

Cons:
- Impossible to express the stable/unstable constraint in terms of 
dependencies
- Impossible to express breaking-change constraint in terms of dependencies
- Special strings either complicate packaging (need to map dependency-safe 
version format to this) or require separate packages for each chain (and if 
they're not parallel installable, further complexity shows up)

> -- Option E -- "ubuntu"
> 
> YY.MM[.Z]
> 
>  - YY is year, MM is month of release
>  - Z for stable updates
> 
>  15.03 hammer final
>  15.03.1 bugfix
>  15.03.2 bugfix
>  ...
>  15.04 infernalis dev
>  15.05 infernalis dev
>  ...
>  15.07 infernalis final
>  15.07.1 bugfix
>  15.07.2 bugfix
>  ...
> 
> Q: What if we have more than one dev release a month?  Like, on a 2 weeks
> schedule, as we have been.
> A: We move to monthly dev releases.  Or, we put an 'a' or 'b' suffix on
> there?  Meh.
> 
> Q: How do I tell if it's a stable release?
> A: It's a triple.

Pros:
- Simple

Cons:
- Impossible to express stable/unstable constraint in terms of dependencies
- Impossible to express breaking-change constraint in terms of dependencies
- Hard to map versions to names
- "Meh" is the _worst_ thing a packager can hear from a dev regarding a 
versioning system

> -- Option F -- "flat"
> 
> X[.Y]
> 
>  - increment X on every release, regardless of whether it is a named
> release or not
>  - add a .Y (or .0) if it is a stable release
> 
>  1.0 hammer final
>  1.1 bugfix
>  1.2 bugfix
>  ...
>  2 infernalis dev
>  3 infernalis dev
>  ...
>  8 infernalis rc
>  9.0 infernalis final
>  9.1 bugfix
>  ...
>  10 j dev
>  11 j dev
>  12 j dev
>  ...
>  17.0 j final
>  17.1 j bugfix
>  ...
> 
> Q: What if the number gets big?
> A: Too late!
> 
> Q: How do I tell if it's a stable release?
> A: double instead of single item

Pros:
- Udev does this... sort of. They don't do points.

Cons:
- Impossible to express stable/unstable constraint in terms of dependencies
- Impossible to express breaking-change constraint in terms of dependencies
- Hard to map versions to names


Now, overall I'm most sympathetic to semantic, for a few reasons:
- Humans care about stable/unstable, sort of - but that's mostly about only 
wanting to update _at all_ in an explicit manner.
- Dependencies care HUGELY about breaking changes, but not at all about 
stable/unstable
- Currently, the libraries and the servers are combined in one version 
number. Because of that, failing to express breaking-change constraints can 
do things like make Qemu fail to run with an error loading shared libraries.
- For language bindings, semantic offers the largest potential for version 
sync
- Mapping between names and versions is a rare event; dependency resolution 
happens on every invocation of the package manager

Re: ceph versions

[David Moreau Simard]

Can I also throw another option out there ?
Openstack uses a version scheme tied to the year of release [1].

Looking back at past releases [2], we can see that for example "Icehouse"
was the first release of 2014: "2014.1".
Icehouse eventually had stable releases which were versioned 2014.1.1,
2014.1.2 and 2014.1.3.
Later that year there was Openstack "Juno" that became 2014.2.

I like this scheme because:
- Solely by itself, it's a good indicator of when your software was last
updated and when the latest release was done
- You can tell how stable, proven or supported it is (2014.1.3 should be
pretty rock solid by the third release!)
- Flexible: If you want to do four releases in the year, there's no
problem going 2015.1, 2015.2, 2015.3, 2015.4 - each with their own dot
releases if necessary

[1] https://wiki.openstack.org/wiki/Release_Naming
[2] https://wiki.openstack.org/wiki/Releases
--
David Moreau Simard


On 2015-02-26, 6:12 PM, "Sage Weil" <sweil@redhat.com> wrote:

>Hammer will most likely be v0.94[.x].  We're getting awfully close to
>0.99, though, which makes many people think 1.0 or 1.00 (isntead of
>0.100), and the current versioning is getting a bit silly.  So let's talk
>about alternatives!
>
>Here are a few of options:
>
>-- Option A -- "doubles and triples"
>
>X.Y[.Z]
>
> - Increment X at the start of each major dev cycle (hammer, infernalis)
> - Increment Y for each iteration during that cycle
> - Eventually decide it's good and start adding .Z for the stable fixes.
>
>For example,
>
> 1.0 first infernalis dev release
> 1.1 dev release
> ...
> 1.8 infernalis rc
> 1.9 infernalis final
> 1.9.1 stable update
> 1.9.2 stable update
> ...
> 2.0 first j (jewel?) dev release
> 2.1 next dev release
> ...
> 2.8 final j
> 2.8.x stable j releases
>
>Q: How do I tell if it's a stable release?
>A: It is a triple instead of a double.
>
>Q: How do I tell if this is the final release in the series?
>A: Nobody knows that until we start doing stable updates; see above.
>
>
>-- Option B -- "even/odd"
>
>X.Y.Z
>
> - if Y is even, this is a stable series
> - if Y is odd, this is a dev release
> - increment X when something major happens
>
> 1.0 hammer final
> 1.0.1 stable/bugfix
> 1.0.2 stable
> 1.0.3 stable
> ...
> 1.1.0 infernalis dev release
> 1.1.1 infernalis dev release
> 1.1.2 infernalis dev release
> ...
> 1.2.0 infernalis final
> 1.2.1 stable branch
> ...
> 1.3.0 j-release dev
> 1.3.1 j-release dev
> 1.3.2 j-release dev
> ...
> 1.4.0 j-release final
> 1.4.1 stable
> 1.4.1 stable
>
>Q: How do I tell if it's a stable release?
>A: Second item is even.
>
>
>-- Option C -- "semantic"
>
>major.minor.patch
>
>- MAJOR version when you make incompatible API changes,
>- MINOR version when you add functionality in a backwards-compatible
>manner, and
>- PATCH version when you make backwards-compatible bug fixes.
>
> 1.0.0 hammer final
> 1.0.1 bugfix
> 1.0.1 bugfix
> 1.0.1 bugfix
> 1.1 infernalis dev release
> 1.2 infernalis dev release
> 2.0 infernalis dev release
> 2.1 infernalis dev release
> 2.2 infernalis dev release
> 2.3 infernalis final
> 2.3.0 bugfix
> 2.3.1 bugfix
> 2.3.2 bugfix
> 2.4 j dev release
> ...
> 2.14 j final
> 2.14.0 bugfix
> 2.14.1 bugfix
> ...
> 2.15 k dev
> ..
> 3.3 k final
> 3.3.1 bugfix
> ...
> 
>Q: How do I tell what named release series this is?
>A: As with the others, you just have to know.
>
>Q: How do we distinguish between stable-series updates and dev updates?
>A: Stable series are triples.
>
>Q: How do I know if I can downgrade?
>A: The major hasn't changed.
>
>Q: Really?
>A: Well, maybe.  We haven't dealt with downgrades yet so this assumes we
>get it right (and test it).  We may not realize there is a
>backward-incompatible change right away and only discover it later during
>testing, at which point the versions are fixed; we'd probably bump the
>*next* release in response.
>
>
>-- Option D -- "labeled"
>
>X.Y-{dev,rc,release}Z
>
> - Increment Y on each major named release
> - Increment X if it's a major major named release (bigger change
>than usual)
> - Use dev, rc, or release prefix to clearly label what type of release
>this is
> - Increment Z for stable updates
>
> 1.0-dev1 first infernalis dev release
> 1.0-dev2 another dev release
> ...
> 1.0-rc1 first rc
> 1.0-rc2 next rc
> 1.0-release1 final release
> 1.0-release2 stable update
> 1.0-release3 stable update
> 1.1-dev1 first cut for j-release
> 1.1-dev2 ...
> ...
> 1.1-rc1
> 1.1-release1 stable
> 1.1-release2 stable
> 1.1-release3 stable
>
>Q: How do I tell what kind of release this is?
>A: Look at the string embedded in the version
>
>Q: Will these funny strings confuse things that sort by version?
>A: I don't think so.
>
>
>-- Option E -- "ubuntu"
>
>YY.MM[.Z]
>
> - YY is year, MM is month of release
> - Z for stable updates
>
> 15.03 hammer final
> 15.03.1 bugfix
> 15.03.2 bugfix
> ...
> 15.04 infernalis dev
> 15.05 infernalis dev
> ...
> 15.07 infernalis final
> 15.07.1 bugfix
> 15.07.2 bugfix
> ...
>
>Q: What if we have more than one dev release a month?  Like, on a 2 weeks
>schedule, as we have been.
>A: We move to monthly dev releases.  Or, we put an 'a' or 'b' suffix on
>there?  Meh.
>
>Q: How do I tell if it's a stable release?
>A: It's a triple.
>
>
>-- Option F -- "flat"
>
>X[.Y]
>
> - increment X on every release, regardless of whether it is a named
>release or not
> - add a .Y (or .0) if it is a stable release
>
> 1.0 hammer final
> 1.1 bugfix
> 1.2 bugfix
> ...
> 2 infernalis dev
> 3 infernalis dev
> ...
> 8 infernalis rc
> 9.0 infernalis final
> 9.1 bugfix
> ...
> 10 j dev
> 11 j dev
> 12 j dev
> ...
> 17.0 j final
> 17.1 j bugfix
> ...
>
>Q: What if the number gets big?
>A: Too late!
>
>Q: How do I tell if it's a stable release?
>A: double instead of single item
>--
>To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ceph versions

[John Spray]

On 26/02/2015 23:12, Sage Weil wrote:
> Hammer will most likely be v0.94[.x].  We're getting awfully close to
> 0.99, though, which makes many people think 1.0 or 1.00 (isntead of
> 0.100), and the current versioning is getting a bit silly.  So let's talk
> about alternatives!

I'm late to this thread, but...

I find option B preferable, because it puts the most important 
information (which series, and is it stable) within the "X.Y" part that 
people will typically use in normal speech.  In an ideal world option D, 
but I have found historically that it gets very confusing to have 
multiple releases with the same number, differentiated only by a 
trailing -dev/-rc.  Folks are prone to drop the critical trailing 
qualifier when they say "I'm running 1.2".  However, option D would be 
my second choice to option B, as its the most explicit of the alternatives.

As for the others... Option A (doubles and triples) has a similar 
abbreviation problem, that people will say "I'm running 1.2" whether 
they were running a 1.2 dev or a 1.2.1 stable.  Option C (semantic) is 
nice for APIs, but for software releases will confuse ordinary humans 
who associate big version jumps with big features etc. Option E 
differentiates between stable/dev with double/triple, which means it too 
has the abbreviation problem when spoken about colloquially.  Option F 
is confusing because it requires the reader to differentiate between "8 
(not 0!)" and "9 (point 0)" to see stability.

Cheers,
John

>
> Here are a few of options:
>
> -- Option A -- "doubles and triples"
>
> X.Y[.Z]
>
>   - Increment X at the start of each major dev cycle (hammer, infernalis)
>   - Increment Y for each iteration during that cycle
>   - Eventually decide it's good and start adding .Z for the stable fixes.
>
> For example,
>
>   1.0 first infernalis dev release
>   1.1 dev release
>   ...
>   1.8 infernalis rc
>   1.9 infernalis final
>   1.9.1 stable update
>   1.9.2 stable update
>   ...
>   2.0 first j (jewel?) dev release
>   2.1 next dev release
>   ...
>   2.8 final j
>   2.8.x stable j releases
>
> Q: How do I tell if it's a stable release?
> A: It is a triple instead of a double.
>
> Q: How do I tell if this is the final release in the series?
> A: Nobody knows that until we start doing stable updates; see above.
>
>
> -- Option B -- "even/odd"
>
> X.Y.Z
>
>   - if Y is even, this is a stable series
>   - if Y is odd, this is a dev release
>   - increment X when something major happens
>
>   1.0 hammer final
>   1.0.1 stable/bugfix
>   1.0.2 stable
>   1.0.3 stable
>   ...
>   1.1.0 infernalis dev release
>   1.1.1 infernalis dev release
>   1.1.2 infernalis dev release
>   ...
>   1.2.0 infernalis final
>   1.2.1 stable branch
>   ...
>   1.3.0 j-release dev
>   1.3.1 j-release dev
>   1.3.2 j-release dev
>   ...
>   1.4.0 j-release final
>   1.4.1 stable
>   1.4.1 stable
>
> Q: How do I tell if it's a stable release?
> A: Second item is even.
>
>
> -- Option C -- "semantic"
>
> major.minor.patch
>
> - MAJOR version when you make incompatible API changes,
> - MINOR version when you add functionality in a backwards-compatible
> manner, and
> - PATCH version when you make backwards-compatible bug fixes.
>
>   1.0.0 hammer final
>   1.0.1 bugfix
>   1.0.1 bugfix
>   1.0.1 bugfix
>   1.1 infernalis dev release
>   1.2 infernalis dev release
>   2.0 infernalis dev release
>   2.1 infernalis dev release
>   2.2 infernalis dev release
>   2.3 infernalis final
>   2.3.0 bugfix
>   2.3.1 bugfix
>   2.3.2 bugfix
>   2.4 j dev release
>   ...
>   2.14 j final
>   2.14.0 bugfix
>   2.14.1 bugfix
>   ...
>   2.15 k dev
>   ..
>   3.3 k final
>   3.3.1 bugfix
>   ...
>   
> Q: How do I tell what named release series this is?
> A: As with the others, you just have to know.
>
> Q: How do we distinguish between stable-series updates and dev updates?
> A: Stable series are triples.
>
> Q: How do I know if I can downgrade?
> A: The major hasn't changed.
>
> Q: Really?
> A: Well, maybe.  We haven't dealt with downgrades yet so this assumes we
> get it right (and test it).  We may not realize there is a
> backward-incompatible change right away and only discover it later during
> testing, at which point the versions are fixed; we'd probably bump the
> *next* release in response.
>
>
> -- Option D -- "labeled"
>
> X.Y-{dev,rc,release}Z
>
>   - Increment Y on each major named release
>   - Increment X if it's a major major named release (bigger change
> than usual)
>   - Use dev, rc, or release prefix to clearly label what type of release
> this is
>   - Increment Z for stable updates
>
>   1.0-dev1 first infernalis dev release
>   1.0-dev2 another dev release
>   ...
>   1.0-rc1 first rc
>   1.0-rc2 next rc
>   1.0-release1 final release
>   1.0-release2 stable update
>   1.0-release3 stable update
>   1.1-dev1 first cut for j-release
>   1.1-dev2 ...
>   ...
>   1.1-rc1
>   1.1-release1 stable
>   1.1-release2 stable
>   1.1-release3 stable
>
> Q: How do I tell what kind of release this is?
> A: Look at the string embedded in the version
>
> Q: Will these funny strings confuse things that sort by version?
> A: I don't think so.
>
>
> -- Option E -- "ubuntu"
>
> YY.MM[.Z]
>
>   - YY is year, MM is month of release
>   - Z for stable updates
>
>   15.03 hammer final
>   15.03.1 bugfix
>   15.03.2 bugfix
>   ...
>   15.04 infernalis dev
>   15.05 infernalis dev
>   ...
>   15.07 infernalis final
>   15.07.1 bugfix
>   15.07.2 bugfix
>   ...
>
> Q: What if we have more than one dev release a month?  Like, on a 2 weeks
> schedule, as we have been.
> A: We move to monthly dev releases.  Or, we put an 'a' or 'b' suffix on
> there?  Meh.
>
> Q: How do I tell if it's a stable release?
> A: It's a triple.
>
>
> -- Option F -- "flat"
>
> X[.Y]
>
>   - increment X on every release, regardless of whether it is a named
> release or not
>   - add a .Y (or .0) if it is a stable release
>
>   1.0 hammer final
>   1.1 bugfix
>   1.2 bugfix
>   ...
>   2 infernalis dev
>   3 infernalis dev
>   ...
>   8 infernalis rc
>   9.0 infernalis final
>   9.1 bugfix
>   ...
>   10 j dev
>   11 j dev
>   12 j dev
>   ...
>   17.0 j final
>   17.1 j bugfix
>   ...
>
> Q: What if the number gets big?
> A: Too late!
>
> Q: How do I tell if it's a stable release?
> A: double instead of single item
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ceph versions

[Sage Weil]

Resurrecting this thread since we need to make a decision soon.  The 
opinions broke down like so:

 A - me
 B - john
 C - alex
 D - loic (and drop release names), yehuda, ilya
 openstack - dmsimard

So, most people seem to like D (below):

On Thu, 26 Feb 2015, Sage Weil wrote:
> -- Option D -- "labeled"
> 
> X.Y-{dev,rc,release}Z
> 
>  - Increment Y on each major named release
>  - Increment X if it's a major major named release (bigger change 
> than usual)
>  - Use dev, rc, or release prefix to clearly label what type of release 
> this is
>  - Increment Z for stable updates
> 
>  1.0-dev1 first infernalis dev release
>  1.0-dev2 another dev release
>  ...
>  1.0-rc1 first rc
>  1.0-rc2 next rc
>  1.0-release1 final release
>  1.0-release2 stable update
>  1.0-release3 stable update
>  1.1-dev1 first cut for j-release
>  1.1-dev2 ...
>  ...
>  1.1-rc1
>  1.1-release1 stable
>  1.1-release2 stable
>  1.1-release3 stable

This initialy made me a bit sad because it wasn't my favorite.  My 
aesthetic issues aside, though, I think more explicit dev vs release 
distinction is important and useful.  I think the main issue is the 
strings in the version which will cause pain for some distros.

Would this make sense instead?

 x.0.z - development releases
 x.1.z - release candidate(s)
 x.2.z - release and bugfix updates

John preferred B (even/odd) because it encodes the important info in the 
x.y portion of the version; I think the above does that too, and a bit 
more succinctly.

What do you think?

If that works for people, the follow-up question is what initial X value 
we should choose.  We could go with 1 (and live with the baggage 
associated with what "1.0" is supposed to mean), or with 9 (J is the 9th 
letter).  And if we do that, should we make the hammer release 8.2.0 or 
stick with 0.94?

sage

Re: ceph versions

[Gregory Farnum]

On Mon, Mar 30, 2015 at 1:01 PM, Sage Weil <sage@newdream.net> wrote:
> Resurrecting this thread since we need to make a decision soon.  The
> opinions broke down like so:
>
>  A - me
>  B - john
>  C - alex
>  D - loic (and drop release names), yehuda, ilya
>  openstack - dmsimard
>
> So, most people seem to like D (below):
>
> On Thu, 26 Feb 2015, Sage Weil wrote:
>> -- Option D -- "labeled"
>>
>> X.Y-{dev,rc,release}Z
>>
>>  - Increment Y on each major named release
>>  - Increment X if it's a major major named release (bigger change
>> than usual)
>>  - Use dev, rc, or release prefix to clearly label what type of release
>> this is
>>  - Increment Z for stable updates
>>
>>  1.0-dev1 first infernalis dev release
>>  1.0-dev2 another dev release
>>  ...
>>  1.0-rc1 first rc
>>  1.0-rc2 next rc
>>  1.0-release1 final release
>>  1.0-release2 stable update
>>  1.0-release3 stable update
>>  1.1-dev1 first cut for j-release
>>  1.1-dev2 ...
>>  ...
>>  1.1-rc1
>>  1.1-release1 stable
>>  1.1-release2 stable
>>  1.1-release3 stable
>
> This initialy made me a bit sad because it wasn't my favorite.  My
> aesthetic issues aside, though, I think more explicit dev vs release
> distinction is important and useful.  I think the main issue is the
> strings in the version which will cause pain for some distros.
>
> Would this make sense instead?
>
>  x.0.z - development releases
>  x.1.z - release candidate(s)
>  x.2.z - release and bugfix updates

The problem with encoding information about the kind of release into
digits is that you have to know what they mean. I guarantee you that
people are going to install dev release by mistake (because it's a
higher-valued point release!) if we go this route.

I didn't vote before because I don't know much about the difficulty
any of these will cause in packaging and distros, but just in terms of
clarity and user experience I really prefer "vanilla" D to the
others...
-Greg

>
> John preferred B (even/odd) because it encodes the important info in the
> x.y portion of the version; I think the above does that too, and a bit
> more succinctly.
>
> What do you think?
>
> If that works for people, the follow-up question is what initial X value
> we should choose.  We could go with 1 (and live with the baggage
> associated with what "1.0" is supposed to mean), or with 9 (J is the 9th
> letter).  And if we do that, should we make the hammer release 8.2.0 or
> stick with 0.94?
>
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html