Tim Landscheidt <[email protected]> writes: > 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?
By putting that into a doc somewhere in the release, presumably :) But I get your point, it should probably be more obvious than that, and your scheme is doing a good job of being obvious. If no one else has something to say about that, we can work on this scheme: - see the diffs between the old 3.0 and HEAD, and extract patches that are bugfixes, to make a 3.1 release - update the version number in HEAD to be 4.0dev - RELEASE! Regards, -- Lucas
pgpMK8vlTrFps.pgp
Description: PGP signature
_______________________________________________ Emms-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emms-patches
