hg summary (and log) can also pull the tags, so if the only tag on it was say "2.3.5" then it'd be available
I need to update the release docs to include the release branching.. -Bill On Wed, Jun 17, 2015 at 4:56 PM, Gary Oberbrunner <[email protected]> wrote: > IMHO, version number alone is fine. Probably the usual process which has > the release on its own branch is why this normally works. But it is > time-consuming so if you want to simplify I'm all for it. > > On Wed, Jun 17, 2015 at 7:40 PM, Bill Deegan <[email protected]> > wrote: > >> Greetings, >> >> I'm fixing some logic in SCons's own SConstruct which sets the revision >> number. >> Currently is has the revision #, changeset has, branch, and whether it's >> modified. >> >> I also notice that 2.3.4 didn't have this info, so I'm guessing it >> bootstrap.py was passed the revision id >> >> (venv)WilliamsMacBook:scons-2.3.4 bdbaddog$ scons --version >> SCons by Steven Knight et al.: >> script: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu >> engine: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu >> engine path: ['/Users/bdbaddog/tmp/venv/lib/scons-2.3.4/SCons'] >> Copyright (c) 2001 - 2014 The SCons Foundation >> >> Should this be the practice going forward? >> Or is there value in having 2.3.5, revision #3252, changeset 385adb84f >> for example? >> >> -Bill >> >> _______________________________________________ >> Scons-dev mailing list >> [email protected] >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> >> > > > -- > Gary > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
