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

[mkurz]

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

[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)

[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.

[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]

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:

• sbt/sbt-release#398
• sbt/sbt-release#397
• sbt/sbt-release#393

[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.

[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.