Re: [fltk.development] FLTK version number update and releaseprocess [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packagedproperly]
On 01.03.2013 11:55, Peter Åstrand wrote: > Suggestion: After the release is done, append "post" to the version number. The version number must be numeric, three parts only, see: http://www.fltk.org/doc-1.3/enumerations.html "The FLTK version number is stored in a number of compile-time constants: FL_MAJOR_VERSION - The major release number, currently 1. FL_MINOR_VERSION - The minor release number, currently 3. FL_PATCH_VERSION - The patch release number, currently 2. FL_VERSION - A combined floating-point version number for the major, minor, and patch release numbers, currently 1.0302." We can't change this, but *maybe* we could _add_ some string to be used in another variable/macro for those who want to get that additional info. FL_VERSION_SUFFIX or something like that, maybe. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK version number update and releaseprocess [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packagedproperly]
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#. If we do a release of 4.5.6 and its svn# is , then we immediately change the version# to 4.5.7 and check it in (svn#6667) and from there we tweak away. > Ideally, I suppose, we might bump it to a "temporary" number, 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). This way if you built an app against a dev version, one could tell from the FLTK version number. 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. Not sure what that number becomes if we ever move to git, though.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK version number update and releaseprocess [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packagedproperly]
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
