[Insight-developers] ITK version numbers

Matt McCormick matt.mccormick at kitware.com
Mon Dec 19 15:04:47 EST 2011


How about

  major.minor.patch.tweak

Where tweak is "0" for a release (edited by a commit), and a YYYYMMDD
time stamp otherwise.  This way can have easy version comparisons and
patch releases.

Matt


On Mon, Dec 19, 2011 at 3:00 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Brad,
>
> What would be best for itk: vtk's or cmake's approach?
>
> On Mon, Dec 19, 2011 at 2:58 PM, Brad King <brad.king at kitware.com> wrote:
>> On 12/19/2011 1:31 PM, Bill Lorensen wrote:
>>>
>>> VTK's is different. VTK in vtkGenerateVTKConfig.cmake has the magic to
>>> create a VTKConfig.cmake that uses the kwsys time stamp.
>>
>>
>> Right, I was thinking only of the version header files.  I forgot about
>> my VTK change for this:
>>
>>  http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=19852427
>>
>> On 12/19/2011 1:31 PM, Bill Lorensen wrote:
>>>
>>> CMake's approach is even better.
>>
>>
>> Thanks.  The only reason CMake uses 4 components is because we regularly
>> release new features in versions that increase only the "patch" number.
>> The approach works equally well for 3-component versions:
>>
>>  major.minor.<patch|date>
>>
>> or any number of components so long as the date is in a component deeper
>> than the one updated for new features.  When that component is a date
>> it means development.  When the component is a small integer it is a
>> maintenance release (the initial release being number 0).
>>
>> Of course the "date" in a development version is meaningful only along
>> one branch of development e.g. "master".  In a world of non-linear
>> development paths (Git) a granular feature-availability test actually
>> needs the history graph to be available for a reach-ability test.
>>
>> -Brad
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com


More information about the Insight-developers mailing list