[Insight-developers] ITK version numbers

[Bill Lorensen]

Sorry I brought this up in the first case.

Apparently, what I thought was a useful and simple solution, has too
many counter examples and what-if's.

Let's just stick with the manual specification of version numbers.

Bill

On Tue, Dec 20, 2011 at 8:26 AM, Brad King <brad.king at kitware.com> wrote:
> 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



-- 
Unpaid intern in BillsBasement at noware dot com