Config to automatically increment to next major, minor or patch version

[mkurz]

I understand how sbt-dynver works and how it comes up with the version string.

However IMHO it would be usefull if there would be a config which increments either the major, minor or patch version, plus ignore the distance.
For example, right now in Play's master branch we are working towards 2.9.0, also we are in the process of moving to GitHub actions and sbt-ci-release and want to publish sonatype snapshots on each push to the master branch.
Right now the version in Play's master branch looks like this:

• 2.8.1+1506-a4b4198b-SNAPSHOT
• 2.8.1+1506-a4b4198b+20220214-1249-SNAPSHOT when dirty

(2.8.1 because the 2.8.1 was tagged before we branched off a 2.8.x branch).
So people asked us already why this is 2.8.1... and not 2.9.0-SNAPSHOT.
So actually what we want to publish to the sonatype repo is:

• 2.9.0-a4b4198b-SNAPSHOT
• 2.9.0-a4b4198b+20220214-1249-SNAPSHOT when dirty

which makes it clearer these are snapshots of the upcoming 2.9.0 release. I think this is what people are used to.
So actually we would have to remove the distance and increment one of the major/minor/patch parts.
The same for the 2.8.x branch right now, it would be nice to publish 2.8.14-...-SNAPSHOT versions instead of 2.8.13+42-....-SNAPSHOT.

Actually we have a pull request already which achieves that, however I think it would be nice to have this build into sbt-dynver: playframework/playframework#11168

[dwijnand]

One of the goals of sbt-dynver is not require build changes, just rely on the git metadata. What you're asking requires making a change to the build from using increaseMinorVersion to increasePatchVersion (or viceversa).

What I suggest instead of tagging the start of the new version series, for instance 2.9.0-M0.

[ihostage]

What I suggest instead of tagging the start of the new version series, for instance 2.9.0-M0.

@dwijnand Sorry, Dale, but it's a not good suggestion 😞 Because it's not only about the new version series, it's about all versions. Having count of tags 2 times more than now is too much, IMHO.

One of the goals of sbt-dynver is not require build changes, just rely on the git metadata. What you're asking requires making a change to the build from using increaseMinorVersion to increasePatchVersion (or viceversa).

Yep, but It's a very small one-time change for the versions series branch. I think that @mkurz proposal makes sense. For sbt-dynver it will be just a few helper functions that don't break current behavior and versions semantic but can be useful for someone who wants to use different semantics like in Play 😉 Let's be honest it's default version semantics for Maven repositories 🤷‍♂️ And how Matthias wrote, Play already has the draft of implementation of this semantics and she can stay in Play, but it looks like she can be implemented in sbt-dynver and useful not only for Play.

[dwijnand]

You're right, it wouldn't be just for new version series, and I can see how once per version series is a lot less work than once per release.

I sympathise with the desire, but I want to be careful adding complexity here. So I may be convinced that this can be added to sbt-dynver is someone wants to send a PR with the code and README changes for this.

[mkurz]

@eed3si9n I think this issue should be re-opened, what do you think (also see last comment where Dale agrees this would make sense if implemented carefully)

[raquo]

Hi, I've been copy-pasting this PlayFramework VersionHelper file between my projects – thanks for that, that helper works exactly how I need it.

Ideally it should be published somewhere to reduce the amount of boilerplate that library authors have to deal with to get the desired behaviour. If adding this version helper to sbt-dynver is controversial, can this perhaps be published as a separate plugin instead? It would still be better than the status quo.

[mkurz]

Hi, I've been copy-pasting this PlayFramework VersionHelper file between my projects – thanks for that, that helper works exactly how I need it.

Nice, happy if it you can reuse it and if it's useful for you 👍

Ideally it should be published somewhere to reduce the amount of boilerplate that library authors have to deal with to get the desired behaviour. If adding this version helper to sbt-dynver is controversial, can this perhaps be published as a separate plugin instead? It would still be better than the status quo.

Hmmm.. actually we could probably publish it under under a separate standalone project in the Play Framework organization. It would be probably just a one time thing to do since it would be just the version helper file which probably never changes. This way we could also use it in all our Play projects...
Of course, ideally, this should still be included in sbt-dynver itself, however I don't have time to implement that currently (and a PR also would need to be accepted by Dale...), so having it as a own project (even if just one file) could be a "ok" solution for now.

[mkurz]

Somehow related, but not really, still linking them here, maybe there is something useful there:

• Incrementing prelease versions by default is unsupported sbt-release#398
• feat: adding prerelease version increments sbt-release#397
• feat: support prerelease version increments sbt-release#393