[Insight-developers] ITK version numbers

Bill Lorensen bill.lorensen at gmail.com
Mon Dec 19 15:45:46 EST 2011


I suggest fot today that we explicitly set the version to 4.1.0.

We can resolve the more detailed solution later.


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


More information about the Insight-developers mailing list