More usual version numbers

[cbeleites]

I propose to move to the more "usual" version number system of having patch numbers in the 3rd place rather than the date.

This has advantages:

• We get one step further to not (or almost never) needing make, i.e. being able to use devtools and RStudio build functionality.
• The current version numbers also trigger a warning on R CMD check --as-cran. This means that on submission to CRAN I always have to add an explanation.

I suggest that hyperSpec version 1.0 is a good point to do that.

[bryanhanson]

I concur with this. I think there are some other things we could do with the Makefile as well, but I'll put those in another issue in the near future. Claudia, should we go ahead and implement x.y.z per semantic versioning now? We could work at 0.99.1 and increment .z for the time being. I can do this if you like, once the all the demons are out of the build system.

[cbeleites]

The difficulty with that is that 0.99.1 < 0.99.20200513
However, with the usual versioning, the version bumps would be manual. And that transition could be done immediately by removing the Makefile target to update the date in the version number while keeping the date system until we step to 1.0.

[bryanhanson]

I use a method that reads DESCRIPTION, and increments whatever value of .z it finds every time you build. So one could set the value to 0.99.3 and let it go from there. I build often, so it’s not unusual for my packages to end up at something like 0.9.339 I think the main thing is that .z be unique for every build. Food for Thought.

…

On May 13, 2020, at 3:10 PM, Claudia Beleites ***@***.***> wrote: The difficulty with that is that 0.99.1 < 0.99.20200513 However, with the usual versioning, the version bumps would be manual. And that transition could be done immediately by removing the Makefile target to update the date in the version number while keeping the date system until we step to 1.0. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABCIPWIGM66YMNXNVTZJWLRRLWDRANCNFSM4M76QTUQ>.

[cbeleites]

CRAN checks include that z needs to be larger than the previous one if x or y did not increase. We can do that though.

[ximeg]

The difficulty with that is that 0.99.1 < 0.99.20200513

@cbeleites Why don't we make 0.100.1, which is bigger than 0.99.whatever?

Here is a link to semver.org for reference.

[bryanhanson]

So what is the desired behavior here? When do you (any of you) want to increment .z? In my own work I increment every time I build, that way there is always a unique version. I think that's consistent with the principles of semantic versioning. But it does create DESCRIPTION files that constantly change date & version. In a group setting we can just live with that, or try to remember not to commit it, or change .z according to... what scheme?

[GegznaV]

Why don't we make 0.100.1, which is bigger than 0.99.whatever?

👍

[ximeg]

So what is the desired behavior here? When do you (any of you) want to increment .z? In my own work I increment every time I build, that way there is always a unique version. I think that's consistent with the principles of semantic versioning. But it does create DESCRIPTION files that constantly change date & version. In a group setting we can just live with that, or try to remember not to commit it, or change .z according to... what scheme?

In my opinion, it makes sense to assign version numbers only to the releases (i.e. commits in the master) branch. As soon as we have a stable state (working builds, no errors, no warnings, no notes) that can go to CRAN, we should start to release (merge to master) on a regular basis.

Once we start the release, we should update the version number:

• No significant changes or only small bugfixes? -> increment .z
• New functionality? New vignettes? -> increment .y
• Changed behavior? New package structure? Breaking things? -> increment x