On 1 Mar 2013, at 15:39, Greg Ercolano wrote: > On 03/01/13 01:33, MacArthur, Ian (Selex ES, UK) wrote: >> What Mike said: As soon as *anything* in SVN changes after a release, we >> need to "bump" the version numbers in some way. > > Or, just change it immediately after release. > Changing the version number is itself a change, and would therefore > bump the svn version#.
Ah, fair point. Though in a sort of "self-fulfilling prophecy" kinda way... > Right, I think linux (or something) used even release numbers for dev > (.0, .2, etc), > and odd numbers for release versions (eg. .1, .3, etc). Yes - I always quite liked that, but they stopped doing it that way... > > Or, we could work the SVN version number into Enumerations.H > (eg. FL_SCCS_VERSION?) which might be nice to have anyway so that > someone with an app can see the FLTK version /and/ SCCS #. > > I think svn allows for hook scripts to be triggered whenever there's > a checkin for this kind of thing. Pretty sure cvs had this too. I use svnversion for this in my own build script, but you are right, the svn hooks can probably do this in a neater way. > > Not sure what that number becomes if we ever move to git, though.. What it becomes, as you know, is a human-opaque string of gibberish... (Technically I understand why it is like that, but I really can't believe we couldn't figure out some way to hide that behind some human-friendly index...) _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
