Push tag(s) for previous releases (0.1.0) and cook up a fresh release

[yarikoptic]

2b118bff49b6a872baa4fb7bc15539e3bcfd8cf6 introduced CTK_*_VERSION variables in 2010, not sure if that was the release though, and they never changed ever since. It would be great if an annotated tag (e.g. 0.1.0) was pushed to the repository for the point of 0.1.0 release. Also it would be nice if CTK got some kind of release schedule -- absence of releases complicates use/provisioning/reliance upon CTK.

Thanks in advance

[gerddie]

I second this. I'd like to create a proper Debian package and there using an official tarball as based is strongly preferred.

[jcfr]

@gerddie That would be great.

I would like to work with you and @domibel to make this happen. I propose we move the discussion about debian package in #608

[pieper]

+1

On Wed, Oct 7, 2015 at 9:45 AM, Jean-Christophe Fillion-Robin < [email protected]> wrote:

@gerddie https://github.com/gerddie That would be great.

I would like to work with you and @domibel https://github.com/domibel to make this happen. I propose we move the discussion about debian package in #608 https://github.com/commontk/CTK/issues/608

— Reply to this email directly or view it on GitHub https://github.com/commontk/CTK/issues/358#issuecomment-146200402.

[djelouze]

+1 Today I use a cmake script to get the git hash of the current CTK version I use. This way, I can inform the user about which exact ctk he is actually running. Such a tracking feature is very important for regulatory issues.

Having an official release will drastically improve the deployment process :)

[jcfr]

Agreed. Working on setting up testing on circle ci using https://github.com/thewtex/docker-opengl when complete, I suggest we address failing test if any and the release 0.1.0

[emmenlau]

Agreed, please use a regular versioned release scheme.

And there is also not too much point in having a versioned installation directory if the version is essentially static :-) :-)