[Insight-developers] ITK version numbers

[Brad King]

On 12/19/2011 5:22 PM, Matt McCormick wrote:
>    . o 4.0.1
>    . |
>    | |
>    o | 4.1.20111219
>    | |<--- fix for nasty bug
>    |/
>    o 4.0.0
>
> Say developer Alice has a project that need the 'fix for nasty bug'
> commit, and she specifies that the ITK version must be>=
> 4.1.200111219.  Then Bob comes with 4.0.1, and he will get an
> inaccurate version insufficiency message.

I actually started to write a paragraph about that case but never
had time to finish it before sending one of my previous messages
in this thread.  Currently the scheme only works when the minimum
version requirement by a project is due to a feature or other change
that will not be backported to an older release and expected to work.

Plain numerical version comparisons only ever work when written with
respect to a single path of development because the numbers increase
monotonically along that path.  If Alice had instead waited until
Bob released 4.0.1 and specified that as the minimum required version
then anyone with a 4.1.$date version between 4.0.0 and the date the
fix was made in the "mainline" will have a version that passes the
check but does not have the fix.  We cannot simultaneously solve both
problems with a simple version number unless we avoid ever backporting
changes and always do incremental releases off a single path of
development.

I'm sure this same discussion has been held in forums for many projects.
The problem is not new with Git.  Even folks using SVN revision numbers
would have the same problem.  The revision number doesn't tell you what
branch is in use.  Use of dates with CVS has the same problems.

Only a version comparison that actually uses the history graph can
answer the question "Is the change introduced by $commit known to this
version?".  Do we want the build to record every Git commit in history,
and to distribute that with source tarballs too?  I don't think that is
practical.  Besides, if we ever need to reconstruct the whole history
graph in terms of a future Git hash algorithm (such as sha1 -> sha256)
then all those hashes will change and existing comparisons won't work.

-Brad K