[Emms-patches] Re: Version numbering scheme

[Tim Landscheidt]

Lucas Bonnet <address@hidden> wrote:

>>> Yeah, we should at least have two branches now:
>>>  - 3.0-maintenance, to apply bugfixes to the released (and quite old)
>>>    EMMS 3.0
>>>  - HEAD, where new code is pushed
>>>  - plus the temporary branches where fun stuff breaks everything, like
>>>    typos-fix and so on, which should eventually get merged into HEAD.

>>> I really need to get up to speed with git :)

>> Oh, I didn't mean to talk about so low-level stuff as bran-
>> ches; I'm thinking more about the user who doesn't "git
>> clone" and still wants to know whether the snapshot he down-
>> loaded from somewhere on the web is "3.0" or "3.0" :-).

> Ah, right. We can start by changing the version numbers in HEAD to
> something different. How about 3.5, which will be changed to 4.0 when we
> do a release?

I don't find picking arbitrary version numbers very help-
ful :-). How would someone know that "3.5" is a "moving tar-
get" and not a well-defined release, but "2.0", "2.1", "3.0"
and "4.0" are?

  To suggest a /scheme/:

- Minor releases advance from x.y to x.(+ y 1).
- Major releases advance from x.y to (+ x 1).0.
- Development versions use the version number of the *next*
  planned (minor/major) release with the suffix "dev".

An example timeline:

   3.0                              release
   +- 4.0dev                        development
   |  +- 4.0                        release
   |     +- 4.1dev                  development
   |        +- 4.1                  release
   |           +- 4.2dev            development
   |              +- 5.0dev         some major changes
   |                 +- 5.0         release
   |                    +- 5.1dev   development
   +- 3.1dev                        maintenance
      +- 3.1                        bug-fix release

Tim