Versioning

[robertmuil]

How should versioning be handled? I would like to see the Datamat class (at least) have a changing version number so that we can query it at runtime.

Any suggestions for implementing this, or reasons why we shouldn't at all?

In previous projects I often stick the SVN revision number in the version string which has downsides but works well.

[nwilming]

In general git can assign tags to commits, just like svn used tags for versioning. So whenever you feel that a new version number is warranted just create a new tag.

Having a version nr. in datamat makes sense for me. Why not simply have the datamat version nr mirror the branch + last git tag that it is based on?

[robertmuil]

Ok, so how would we implement that? I used SVN's string replacement capability (svn:keywords) to implement it in SVN - so that I had a string suchly:

__revision_str__ = "$Revision: 986 $" __revision__ = int(__revision_str__.strip(' \t$').rsplit(':',1)[1].strip())

And then I could use __revision__ anywhere in my code. Advantage was that it was automatically updated, and guaranteed to be different for every commit. We could then implement a more human-friendly version number (e.g. 1.2) manually through tagging.

[nwilming]

OK, I think this is something that could work:

We create tags for every version that is worthy of a 'full' release. Then we use a post-commit hook to generate a 'VERSION' file that creates the name of the last tag. Conveniently the 'git describe' command does just that, even better, it appends some meaningful stats (like the nr of commits done since the last tag).

So if you put this:
git describe > VERSION
into ocupy/.git/hooks/post-commit the VERSION file is updated on every commit.