Re: [PATCH] Integrate git-version-gen.

[Arsen Arsenović]

Hi Jose,

"Jose E. Marchesi" <jemarch@gnu.org> writes:

> Hi Arsen.
>
>> diff --git a/HACKING b/HACKING
>> index 123dbc57..5325092d 100644
>> --- a/HACKING
>> +++ b/HACKING
>> @@ -234,6 +234,21 @@ with GNU poke.  If not, see 
>> <https://www.gnu.org/licenses/>.
>>    The standard target `make distcheck' builds a distributable sources
>>    tarball, and tests that it can be built and tested properly.
>>  
>> +  Note that if you're working on a checkout that is not fresh (i.e. it
>> +  has had commits or tags since you last ran `./autogen.sh'), it is
>> +  desirable to re-run `./autogen.sh', or otherwise regenerate
>> +  `configure', to get updated version information.  This version will be
>> +  stored in the newly-generated dist tarball.
>
> So, what is the procedure to change the program version?  Right now it
> is by changing the version in AC_INIT in configure.ac.
>
> Let's see:
>
> - If `make dist' is executed on a HEAD that has a releases/poke-X.Y[.Z]
>   note in it, the version used will be "X.Y[.Z]".
>
> - If `make dist' is executed on a HEAD that has no such tag, then the
>   version used will be... what, something based on the git commit-id of
>   HEAD?

Yes.  Earlier today I locally tagged
4c25bab951e8d6bfc6a7a450f95ba9106fa00f37 ("prepare for 2.90.0" on
master) as releases/poke-2.90.0 and then built a dirty copy of
a67097981e605cd2eb1b683b71952ffe5878529f, which resulted in:

  ~/gnu/poke/_build$ ./run poke --version
  GNU poke 2.90.0.18-a670-dirty

  (n.b. the commit   ^^^^)

If you build on a clean checkout of a tag, you get:

  ~/gnu/poke/_build$ ./run poke --version
  GNU poke 3.0

(I tagged a67097981e605cd2eb1b683b71952ffe5878529f as 3.0 for a test and
stashed my changes, then touched configure.ac, to generate the result
above)


The step of changing the version in configure.ac is substituted with
regenerating configure, which will then automatically determine the
appropriate version based on the latest tag.  Personally, I'd copy the
NEWS outline for a release into the tags message, but you could opt for
something more brief instead, if you wish.

>> +  Keep in mind that, when regenerating, a dirty tree, including
>> +  differently dated submodules, will cause the version to be suffixed
>> +  with `-dirty'.
>
> What is exactly a "dirty build"?

A dirty tree is a git checkout on which there are modifications, i.e. a
checkout in which files that are tracked in git aren't in a commit.  To
quote the git-describe(1) page:

     --dirty[=<mark>], --broken[=<mark>]
         Describe the state of the working tree. When the working tree
         matches HEAD, the output is the same as "git describe
         HEAD". If the working tree has local modification "-dirty" is
         appended to it. If a repository is corrupt and Git cannot
         determine if there is local modification, Git will error out,
         unless ‘--broken’ is given, which appends the suffix
         "-broken" instead.

>> +  Should this happen, and you want to go through with
>> +  the release anyway, `git stash' your changes and `git submodule
>> +  update' submodules, so that they get checked out to in-tree revisions.
>> +  This also ensures that you're testing the version of the tree that
>> +  will make it into a release, rather than something with a potentially
>> +  uncommitted fix, or suchlike.
>
> I don't understand that paragraph. "go through with the release" means
> executing `make dist'?

Yes, if you want to continue the release procedure knowing that your
local checkout did not match what would be in a clean dist tarball,
i.e. knowing that what you were testing up until the point of release is
not what will be released, you can simply stash the changes to get a
clean tree immediately, regenerate configure, and re-run distcheck,
which will produce a clean version.  The scenario I am imagining here is
fixing a bug and not committing it (because it was late or something)
and then making a release the next day, overlooking that you had an
outstanding bugfix.


Keep in mind that, since this is pulled in via m4_esyscmd, the tag is
checked at configure generation time.  This is to avoid excess rebuilds
impeding normal development (which normally invokes producing plenty of
commits or moving around history a lot, which could easily mean lots of
time spent waiting for autoconf).
-- 
Arsen Arsenović

signature.asc
Description: PGP signature