|
From: Cary R. <cy...@ya...> - 2008-04-07 04:46:38
|
--- Jeevan Varshney <jva...@ya...> wrote:
> make dist TAG=<tagname>
Make sure you remember that a distribution does not contain any
configuration information and the Makefiles are part of that, so it
appears we will need to use the Makefiles from our build tree to do the
make dist, but we want the version information to only apply to the
distribution being built. We want the git build tree to reflect the latest
version info. I don't think this is a big deal it just all has to be kept
straight.
This does bring up a question. For snapshots and releases it's fairly easy
to figure out what the version should be, follow the existing pattern
0.8.6, 0.9.devel (<snapshot date>), but what version is the latest git
(either 0.8 or 0.9)? It would be nice is we could identify that the build
was being done in a git repository and use the latest information possibly
something like 0.8.6 + git(<latest git patch date>) and 0.9.devel +
git(<...>). Ideally this would be done automatically without a bunch of
extra files being regenerated (definitely avoid having to rerun autoconf).
Something like:
git pull
make
<remakes any files changed in the pull and also the main driver programs
that contain version information>
The version files should probably also be updated when we do a local
commit, but while it could be useful, I think local changes (when we are
working on bugs) should not trigger a version change. Can we distinguish
between a main commit and a local commit? If so showing the version as
"local" could be nice. We just have to make sure it gets switched to
normal when the patch finally makes it into the main repository.
Thanks for taking care of this!
Cary
____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
|