Versioning after release

Developers
21

Great! The PR is at 2.25.9999 already!

22

In python we use -dev suffix

23

.9999 seems like a hack to me.

in favor of bumping to the next patch number, were one to be needed.

this is not the kind of thing where we want to introduce our own ideosyncratic numbering system that needs to be explained to new devs over and over again - I think we should go with standard practice. if someone finds standard practice confusing, thatā€™s a problem, but if we stray from standard practice, then a whole lot more people are going to be confused. (cf this very helpful post on versioning and the git workflow: https://gist.github.com/stuartsaunders/448036/5ae4e961f02e441e98528927d071f51bf082662f)

this is what was worked out a long time ago: https://github.com/stan-dev/stan/wiki/Developer-process-overview#1-overview

24

donā€™t you get this for free with GitHub hashes?

25

In general, the version numbers should be consistent. The development version of 2.24.0 isnā€™t consistent with the release of version 2.25.0. But, we can follow a standard versioning convention. What about appending a 4th level 2.25.0.9000 like in R or a suffix 2.25.0-dev, 2.25.0-git, or 2.25.0-<commit_hash>?

26

I get the point of versioning.

Just a reminder that we will probably break a lot of current scripts people are using.

1 Like
27

How would bumping the development version break a script if we stick to the same versioning policy?

28

the CmdStan install scripts check version numbers. the implementations are pretty brittle - thereā€™s logic for handling release candidate suffixes as well and we havenā€™t been real consistent about those.
so yeah, theyā€™ll probably break.

29

Ok. As a compromise, the PR now uses a single version inherited from the last release; i.e., it bumps the version in the develop branch to the current version (from 2.24.0 to 2.25.0). This way, nothing will be broken and future release should be a branch using the last version bumped first in the develop branch.

1 Like
30

What we currently do in Stan would not be considered standard practice.

Not sure on Python but Ari says its -dev.

There is no easy check to test that for example (33257cd2 > 2.25.0).

This makes me think my comments may have been confusing. The install scripts work with releases not develop version.

This proposal has nothing to do with releases, nothing changes there, its about how we handle the time in between.

This is where Stan has not followed the standard practices at all, at least in the past. Immediately after any feature PR is merged, we can no longer release current develop as a patch releases. By the SemVer book, patches should always be done to the master branch in our case. Meaning that 2.25.1 is ā€œmaster (2.25.0)ā€ + patch not ā€œcurrent developā€ + patch. This is how we did 2.24.1 and 2.22.1

2.19.1 on the other hand was done as ā€œdevelop + whatever was merged in between + patchā€. That is 2.20.0, not 2.19.1.

So for example current develop can never actually be released as 2.25.1. It can only be released as 2.26.0 or 3.0.0. Which is why I said even 2.25.999 is actually fine, because it signals just that, that this can no longer be a patch release.

But, this is not a ā€œhill I am willing to die onā€ so I am going to stop here. It seems that others have a stronger opinion here than me and we can leave things as is.

My vote would go for 2.25.0.9000, 2.25.0-dev , 2.25.0-git , or 2.25.0-<commit_hash> like @hsbadr suggested.

Will merge the PR with the obvious fix from 2.24.0 to 2.25.0.

3 Likes
31

this makes sense to me.
thanks for the clear explanation.

2 Likes
32

What we currently do in Stan would not be considered standard practice.

Why are those dependencies not submodules or linked externally? If thereā€™re any required source code modifications, I think they can be implemented in the Stan build files.

Iā€™m talking about the libs in math/lib and their upgrade scripts.

1 Like
33

For some we do a bit of patching that would be hard to automate I think. For others it might make sense yeah. As long as we have them in the release tarball to avoid installation problems, I think we are good.