Lucas Bonnet <[email protected]> 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
_______________________________________________
Emms-patches mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emms-patches
