For review: using "git describe" for version numbers

[Dustin]

I thought it'd be good to get more automation around releases and
more easily identifiable builds, so I figured I'd leverage git a bit
more and have it do the work.

Fitting it into automake was a bit weird, but here's what I came up
with:

autogen.sh runs version.sh which generates version.m4 using the
output of `git describe`

version.m4 is included in configure.ac and is therefore a dependency
on builds.

verison.m4 is *not* automatically updated (well, it is for me as I'm
using a post-commit hook), but any update to it will cause a
reconfigure.


Example release process:

git tag -s 2.0
./version.sh
make dist # generates memcached-2.0.tar.gz


PROS:

First, you don't have to touch the configure.ac file to line up with
your releases anymore. Version information exists in one place.

Also, if we wanted to just have downloadable ``nightly'' kinds of
releases out of buildbot or similar, they'd all be perfectly
identifiable:

STAT version 1.3.2-40-g8186473

That version number works wherever commit hashes and the like are
accepted, so you can check tree diffs, log diffs, etc... while still
having a human readable version number.

If the tree is *exactly* on a tag (as in the 2.0 example), the
version number will be exactly the name of the tag.

CAVEATS:

Because it doesn't automatically generate the version without a post-
commit hook, your stuff could be off a little bit in a local build. I
*could* have it automatically do it, but then every build would run
configure and that'd just be annoying.

[Dustin]

Oh, patch might be good...

http://github.com/dustin/memcached/commit/923a335bf8613696d658448cd9c48a963924d436

commit 923a335bf8613696d658448cd9c48a963924d436
Author: Dustin Sallings <dus...@spy.net>
Date: Mon Mar 9 11:52:25 2009 -0700

Use git's version number for releases.

This will allow more specific version numbers, while simplifying a
proper release down to a tag and make dist.

During development, ./version.sh needs to run periodically to
update
the version number. I'd recommend just adding a call to
version.sh as
a git post commit hook:

% cat .git/hooks/post-commit

echo "Updating version."
./version.sh

(and make sure the file is executable)

diff --git a/.gitignore b/.gitignore
index 195b246..f3d6757 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,4 +33,5 @@ memcached-*.tar.gz
doc/protocol-binary-range.txt
doc/protocol-binary.txt
/sizes
-/internal_tests
\ No newline at end of file
+/internal_tests
+/version.m4
diff --git a/Makefile.am b/Makefile.am
index 4cf00b4..af41fe4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -58,7 +58,7 @@ memcached_debug_dtrace.o: $(memcached_debug_OBJECTS)

SUBDIRS = doc
DIST_DIRS = scripts
-EXTRA_DIST = doc scripts TODO t memcached.spec memcached_dtrace.d
+EXTRA_DIST = doc scripts TODO t memcached.spec memcached_dtrace.d
version.m4

MOSTLYCLEANFILES = *.gcov *.gcno *.gcda *.tcov

diff --git a/autogen.sh b/autogen.sh
index 873f0a4..3db9801 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -7,6 +7,9 @@
# apt-get install automake1.7 autoconf
#

+# Get the initial version.
+sh version.sh
+
echo "aclocal..."
ACLOCAL=`which aclocal-1.10 || which aclocal-1.9 || which aclocal19
|| which aclocal-1.7 || which aclocal17 || which aclocal-1.5 || which
aclocal15 || which aclocal || exit 1`
$ACLOCAL || exit 1
diff --git a/configure.ac b/configure.ac
index 182b105..f3fa8b7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,6 @@
AC_PREREQ(2.52)
-AC_INIT(memcached, 1.3.2, br...@danga.com)
+m4_include([version.m4])
+AC_INIT(memcached, VERSION_NUMBER, br...@danga.com)
AC_CANONICAL_SYSTEM
AC_CONFIG_SRCDIR(memcached.c)
AM_INIT_AUTOMAKE(AC_PACKAGE_NAME, AC_PACKAGE_VERSION)
diff --git a/version.sh b/version.sh
new file mode 100755
index 0000000..8a58aef
--- /dev/null
+++ b/version.sh
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+if git describe > version.tmp
+then
+ echo "m4_define([VERSION_NUMBER], [`tr -d '\n' < version.tmp`])"
\
+ > version.m4
+fi
+rm version.tmp

[dormando]

Initially I thought hey, that'll probably break shipit, then I remembered
shipit's just used for every other project I ship.

Seems fine to me. Maybe add the git steps into the HACKING or README or
whatever file somewhere?
-Dormando

[Trond Norbye]

Seems fine to me as well.

Btw. should we replace: br...@danga.com with: memc...@googlegroups.com
??

From the output of configure:
Report bugs to <br...@danga.com>.

I guess he doesn't want to answer all bugs himself?

Cheers,

Trond

--
Trond Norbye

OPG, Database Technology Group E-mail: Trond....@Sun.Com
SUN Microsystems Phone: +47 73842100
Haakon VII's gt. 7B Fax: +47 73842101
7485 Trondheim, Norway

[Dustin]

On Mar 27, 7:17 am, Trond Norbye <Trond.Nor...@Sun.COM> wrote:
> Seems fine to me as well.

I've gone ahead and pushed it. Thanks everyone.

> Btw. should we replace: b...@danga.com with: memc...@googlegroups.com

> ??
>
>  From the output of configure:

> Report bugs to <b...@danga.com>.

>
> I guess he doesn't want to answer all bugs himself?

That makes sense to me. Probably good to have a separate thread so
that he might notice it as well.