[Insight-developers] ITK version numbers

[Matt McCormick]

As Brad remarks in the Gerrit comments, if we go the

  major.minor.<patch|date>

route, where the third number is a bug fix number if it is a release
or a date if it is not.  In this setup, evenness of the minor number
is not needed to indicate a release; if the third number is large, it
is not a release.

Do we want to keep the convention of minor versions always being even
for releases?  The minor version will always be even in this case.

Opinions?

Matt

On Mon, Dec 19, 2011 at 3:34 PM, Matt McCormick
<matt.mccormick at kitware.com> wrote:
> On Mon, Dec 19, 2011 at 3:18 PM, Brad King <brad.king at kitware.com> wrote:
>> On 12/19/2011 3:04 PM, Matt McCormick wrote:
>>>
>>> How about
>>>
>>>   major.minor.patch.tweak
>>>
>>> Where tweak is "0" for a release (edited by a commit), and a YYYYMMDD
>>> time stamp otherwise.
>>
>>
>> This is CMake's approach exactly.  We've never actually done a "tweak"
>> release beyond 0 since switching to this scheme but the version number
>> has room for it.
>>
>>
>>> This way can have easy version comparisons and patch releases.
>>
>> I'm not sure it works for ITK's model.  In ITK we do lots of development
>> in master and occasionally update older releases with new patch levels.
>> The patch number on old release branches that gets updated for fixes
>> must be in the same component as the date on master.  In other words,
>> if we have a branch for "4.0.x" then the date stamp on master needs
>> to be in the ".x" component.  If the latest release is 4.0.0 then
>> the version on master should be "4.0.$date".  If we port a fix back
>> to the release then we create "4.0.1" as the patch release.
>>
>> With ITK's historical release behavior I think the scheme
>>
>>  major.minor.<patch|date>
>
> Implemented in patch set 3:
>
>  http://review.source.kitware.com/#change,3545
>
> Thanks,
> Matt
>
>
>>
>> makes the most sense if we use the date at all.
>>
>> -Brad