Versioning after release

Developers
1

A recent PR in stan-dev/stan has proposed that we bump the minor version on develop branches in Stan. I think this is a good idea as we want to distinguish that a develop branch is newer than a release. I thus feel we should do this in Math and Cmdstan as well. I am just no sure on how to number.

Our current policy is that we bump the minor version on release (for example to 2.25.0) and it stays that way until the next release. If there is a patch release we bump the patch number and that is all.

So the questions is to what do we set the package version after a release. R package use 2.25.0.9000 or something like that, but we dont have the fourth level in the version.

Should we do

a) 2.25.9000
b) 2.25.999
c) add the fourth level so its 2.25.0.9000
d) leave it as is.

Tagging a few devs that might have an opinion here, but anyone is welcome to chime in as usual.

cc: @bbbales2 @syclik @avehtari @mitzimorris @jonah @ariddell @ahartikainen

3 Likes
2

Should we be 2.25.0 in develop?

Would bumping to 2.25.1 be good enough? The problem here isn’t quite that Stan changed, but something about stanc2 and stanc3.

1 Like
3

I would say no which is why I opened this discussion.

I mean this in general, not just the changes this time. Anything could change, Math/Stan/Cmdstan/Stanc3.

4

Another idea is to have
PROJECT_DEVELOPMENT_VERSION version in addition to PROJECT_VERSION.

5

Oh did stan-dev/stan not get a 2.25 release?

6

It did, but it seems that the version makefile variable was not updated. But that is a separate problem. @hsbadr has taken care of that.

It just reminded me that we should somehow note that develop > last release.

1 Like
7

I’d argue that the development version should be consistent with the convention/policy for the releases, meaning that if there’s a major change (new features or API changes), the major number gets bumped building on the last release (same for the minor and patch numbers). But, since the patch number would be moving quickly, the development version should keep it at the maximum value (typically, 3 digits = 999). This is exactly what I proposed here.

1 Like
8

I like that thinking.

Maybe we should just do that? Lets wait a few days to see if anyone disagrees.

9

Or should we be bumping the patch version with pull requests?

Sticking it at 999 in develop seems strange cuz you could have something 2.25.999 older than 2.25.1, for instance

10

That is a hassle and a magnet for conflicts.

11

True and I don’t like it for that reason.

We could bump twice at release, once for the release number, and once for the new develop.

12

Yes, I think that would be the best. The question is to what number do we bump after the release? 2.x+1.0

13

Bumping the minor number seems good.

14

Do you mean that the current development version should be v2.26.0? With a new release, it doesn’t make sense that the minor numbers diverge with no changes in the source code, but the max patch number of 999 will always indicate that it’s a development version. The major and minor numbers can only be bumped with relevant changes. So, if the development branch has merged minor changes from the stable release v2.25.0, the development version will be v2.26.999… and so on.

The X.Y.999 indication of a development version is important too, when referring to a user issue for example (minor versions can get mixed unless you keep track of them).

Also, think about release candidates! It’d be confusing to bump the minor version when the last version hasn’t been released yet.

15

Another option is to automatically append the last commit hash to the version, something like 2.25.0-30c9419 and remove it for the releases.

16

I think going with 2.25.9999 might be the simplest solution here.

We are not going to have ever have 10k patch releases when this becomes a problem.

If we have to do a patch release we change to 2.25.1 and then move back to .9999.

17

Sounds good to me. I can add another patch digit if everyone agrees.

18

I think this is a good idea.

For the R packages, like @rok_cesnovar mentioned, we would do 2.25.0.9000 and I think that’s pretty common in R because it’s recommended in Hadley’s R packages book (if I recall correctly). Here’s the current DESCRIPTION file for bayesplot, which has version 1.7.2.9000:

Yeah that makes sense.

19

Agreed. It’s common in R tidymodels, tidyverse, and RStudio in general to see X.Y.Z.9000 for the development version. Do you prefer 2.25.9999 or 2.25.0.9000?

1 Like
20

No strong preference. I’d be fine with either of those for Stan.

1 Like