Set current NEST version to '3.0.0-SNAPSHOT'.

[DimitriPlotnikov]

The version number for the NEST Head in the repo until the next release will be 2.11

[heplesser]

Shouldn't this be v3.0.0-SNAPSHOT? And wouldn't it be better to build this string automatically from NEST_VERSION_VERSION defined in CMakeLists.txt?

[apeyser]

Hmm, making a file-creator script creator. Sounds complex. I guess it could grep out of config.h as well, or use a c preprocessor to extract it. A bit complex as well. Maybe source a very small file that does the version definition made by cmake?

Or maybe just stick this all in cmake and just add an operator that pulls it from config.h?

Tracking version control information inside of projects is always painful, and I tend to think not so useful without the build infrastructure, and if you have the build infrastructure, you already have that information in the tree.

Maybe we only want to track "Is this release version X" or "You built this yourself, you should know how to give us the hash"?

[apeyser]

http://xit0.org/2013/04/cmake-use-git-branch-and-commit-details-in-project/

That could simplify (eliminate) all this code, if we really want to insert the hashes in sli; on the other hand, inserting it in sli instead of c defeats the goal of making a complete and clear c api.

[heplesser]

In principle ok, provided my inline comments are addressed.

@jougs @apeyser @mschmidt87 What to you think?

[apeyser]

@heplesser

As per issue #411 , I'd suggest we go to even/odd numbering. It's not a big deal, but if we go with -SNAPSHOT, immediately at the time of a release, we have to commit to whether the next release is a big release or a small release. We don't have an option without confusing ourselves about what's going on.

We've already had this happen with 3.0, with discussion after 2.8 whether the next release was a 2.x or a 3.0.

[heplesser]

@apeyser I agree with you in principle. My thought right now was that 3.0 is going to be the next big one, so we could use this patch as a temporary fix and then define a long term policy in our meeting in two weeks. But we might as well wait two+ weeks and then fix it for real.

[apeyser]

@heplesser Then we should accept, if the decision is fixed that we definitely will not be putting out any other major revision than 3.0. No practical consequence. Then afterwards, we can decide.

[terhorstd]

I would agree to apeyser that we don't initially want to commit ourselves to the upcomming version number. What about first sorting the current issues to milestones and then actually planning the versions a bit more in advance? I don't see a reason why there shouldn't be a 2.12 and a 3.0 milestone in parallel. We could properly sort the issues with major changes to the new major version and the others to 2.12.

[heplesser]

We decided in the Open NEST Developer VC today that we will use odd minor version numbers numbers for NEST in between releases, with no further detailing. Thus, the version number for the NEST Head in the repo until the next release will be 2.11.

We may create -RC version numbers on release branches shortly before a release.