[Insight-developers] ITK version numbers

[David Cole]

On Mon, Dec 19, 2011 at 4:28 PM, Brad King <brad.king at kitware.com> wrote:
> On 12/19/2011 4:03 PM, Matt McCormick wrote:
>>
>> As I understand it, if we have dates in the patch version field, we
>> cannot also have add minor indicating a non-release, and still have
>> meaningful version comparisons.
>
>
> We can.  VTK does it.  Bill L. is using it in the VTK examples.
>
> Version number updates will look like this (time goes up):
>
>  o 4.3.20120601
>  |
>  o 4.2.0
>  |
>  o 4.1.20120601
>  |
>  .
>  . o 4.0.1
>  . |
>  | |
>  o | 4.1.20111219
>  | |
>  |/
>  o 4.0.0
>
> -Brad
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers


I don't think using the date in the version number is tenable long
term now that we've switched to git as the version control system. It
only makes sense when:

- you have a heartbeat commit every single day regardless of whether
anything else is changing
- you're making the comparison on a single known branch on which the
heartbeat commit takes place

We're trying, trying, trying to get to a system in the CMake project
where we do not have to have this heartbeat commit. One of the things
we're going to do eventually to get away from it is rely on "git
describe" output to come up with the last bit of the version number.

NO DATE.

At least that's the way I lean. If somebody has a compelling
counter-argument, I'd like to hear it.


David C.