[Insight-developers] ITK version numbers

[Bill Lorensen]

I like minor even indicating a release.

On Mon, Dec 19, 2011 at 3:47 PM, Matt McCormick
<matt.mccormick at kitware.com> wrote:
> 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



-- 
Unpaid intern in BillsBasement at noware dot com