Extract out a versioning plugin

[dwijnand]

I dig your versioning. I think it's better than sbt-dynver, or at the very least I'd like to try it out and compare them in real projects.

Do you mind if we extract it out, like sbt-travisci? Looks like sbt-semver isn't taken, so we could use that.

I don't know where all the pieces are, and exactly where to draw the line between the versioning and the integration with the other parts of this plugin. Any advice?

[djspiewak]

@dwijnand I absolutely don't mind at all extracting it out! The main reason I haven't so far is just that it's relatively close to sbt-dynver (I didn't want you to feel like I was stepping on you) and because I wasn't quite sure where to draw the line on functionality. I think where I specifically got hung up was on the release alias, which is obviously dependent on the bintray/sonatype. But I think we can perhaps pare that away. Or maybe we can do the alias in a way which is more polymorphic and delegates to a task (or tasks) which will be implemented differently by different plugins?

sbt-semver would be an amazing name, though I do like the fact that the versioning scheme makes allowances for the non-strict semver that Scala follows (along with large parts of the ecosystem).

I think the main pieces that define the versioning are simply in SpiewakPlugin, specifically the baseVersion stuff and really everywhere that it interacts with sbt-git. If we extracted just those bits, would that be useful on its own? Do we want the release alias as well? That would obviously conflict with sbt-release, though IMO sbt-release becomes somewhat less useful when using a versioning scheme like this one. WDYT?

[dwijnand]

The main reason I haven't so far is just that it's relatively close to sbt-dynver (I didn't want you to feel like I was stepping on you)

Aww... ❤️

Yeah, the release alias isn't something I was initially interested in. Though I also don't know exactly what it does so I might be missing out. I can look into it an form more of an opinion and see if it can live decoupled.

sbt-semver would be an amazing name, though I do like the fact that the versioning scheme makes allowances for the non-strict semver that Scala follows (along with large parts of the ecosystem).

What allowances? If it's followed by the ecosystem, that's what "semver" is as far as the ecosystem is concerned, I'd say. If someone one more pure comes along they can damn us to hell... and then pick another plugin name :wink:

So I'll start teasing this apart, and see what I make of the release alias.

Are you ok with switching to process-calling git rather than sbt-git/jgit, like in sbt-dynver?

[djspiewak]

Though I also don't know exactly what it does so I might be missing out.

You're definitely missing out. Here's the definition for the sonatype plugin:

addCommandAlias("release", "; reload; project /; +mimaReportBinaryIssues; +publish; sonatypeReleaseAll")

The mima and reload stuff is part of why I consider this part-ish of the versioning. Anyone who uses this kind of dynamic versioning is going to want something like this, due to the fact that version is a setting and not a task.

What allowances? If it's followed by the ecosystem, that's what "semver" is as far as the ecosystem is concerned, I'd say. If someone one more pure comes along they can damn us to hell... and then pick another plugin name 😉

Fair! :-) The allowances that are made btw are binary breakage within a major release line, so long as they remain source-compatible. This can be disabled by changing the useStrictSemver setting (I think that's it?) to true, which gets you enforced compatibility across the entire line. I still need to work on refining the rules here.

So I'll start teasing this apart, and see what I make of the release alias

IMO the MiMa stuff should go along with this; what do you think? Ideally with a slightly improved rule inference in the strict case, since I believe that's buggy right now.

Are you ok with switching to process-calling git rather than sbt-git/jgit, like in sbt-dynver?

Absolutely! It's already mostly doing process calling already since jgit bugs out in certain cases. We can just change it over completely and remove the sbt-git dependency.

[dwijnand]

You're definitely missing out. Here's the definition for the sonatype plugin:

addCommandAlias("release", "; reload; project /; +mimaReportBinaryIssues; +publish; sonatypeReleaseAll")

Ah right. I just +publish on master Travis CI builds to Bintray, and if they weren't sbt plugins I'd bintrayRelease and sync to maven there too. So I don't need the convenience alias.

binary breakage within a major release line, so long as they remain source-compatible

Ah right. Yeah, that's quite the departure. In Lightbend we're moving back to strict SemVer (e.g in sbt, Lagom), so we might want to think about what to do or what plugin name to use.

IMO the MiMa stuff should go along with this; what do you think?

Yep, makes sense for this to come right out the box with it.

Cool. I'll ping here when I rotate back to this.

[djspiewak]

Ah right. I just +publish on master Travis CI builds to Bintray, and if they weren't sbt plugins I'd bintrayRelease and sync to maven there too. So I don't need the convenience alias.

It's more about the fact that people often do something like this:

1. Open SBT
2. Hack hack hack
3. git tag v1.0.0
4. +publish

At step 4, they'll be unpleasantly surprised to discover that they published the wrong version. It's even worse with snapshots, which will have the wrong git hash. Also, an alias (or something) like this is necessary to bind MiMa inextricably to the release process, which is really what we want.

Ah right. Yeah, that's quite the departure. In Lightbend we're moving back to strict SemVer (e.g in sbt, Lagom), so we might want to think about what to do or what plugin name to use.

Yeah it's definitely a departure from semver. I think a lot of people have been using the term "scalaver" to describe it. Honestly, I would rather the default of this plugin be strict semver, and then a setting can control using scalaver for projects which want it. I think it's still fair to use the name sbt-semver, especially if the defaults are strict.