-
Notifications
You must be signed in to change notification settings - Fork 50
Add tlLatestVersion
, tlLatestPreReleaseVersion
to versioning plugin
#333
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
bce0230
defe6b3
9572683
210a174
f23c6d2
085bdd1
c58d30b
4852218
4e2eb8e
91d747d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,6 +18,7 @@ package org.typelevel.sbt | |
|
||
import com.typesafe.sbt.GitPlugin | ||
import com.typesafe.sbt.SbtGit.git | ||
import org.typelevel.sbt.TypelevelKernelPlugin._ | ||
import org.typelevel.sbt.kernel.GitHelper | ||
import org.typelevel.sbt.kernel.V | ||
import sbt._ | ||
|
@@ -37,6 +38,12 @@ object TypelevelVersioningPlugin extends AutoPlugin { | |
lazy val tlUntaggedAreSnapshots = | ||
settingKey[Boolean]( | ||
"If true, an untagged commit is given a snapshot version, e.g. 0.4-00218f9-SNAPSHOT. If false, it is given a release version, e.g. 0.4-00218f9. (default: true)") | ||
|
||
lazy val tlLatestVersion = settingKey[Option[String]]( | ||
"The latest tagged version on this branch. Priority is given to the latest stable version, but if you have tagged a binary-breaking prelease version (such as a milestone or release candidate), that will be selected instead. If applicable, this will be the current tagged version.") | ||
|
||
lazy val tlLatestPreReleaseVersion = settingKey[Option[String]]( | ||
"The latest tagged version on this branch, including milestones and release candidates. If applicable, this will be the current tagged version.") | ||
Comment on lines
+42
to
+46
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok, @bplommer, what do you think? phew 😓 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm happy with that 👍 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On second thought, what do you think about There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Ok yeah that's super fair. But that is quite a mouthful. What if we used the terminology "previous version" instead of "latest"? Then maybe it would be more clear it's relative to our current context. The problem is that it muddies the fact that this can be the current version if the current commit is tagged. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't like "previous", for the reason you give - to me that explicitly rules out it being the current one. But I don't have any other suggestions at the moment 🤔 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I can't think of anything! But I can imagine wanting the "latest prerelease" version on the 0.23.x branch to be a 1.0 milestone, so I could populate the website's landing page accordingly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In that case, shouldn't the landing page be published from There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, I guess not necessarily. My proposal in #317 aims to reduce that complexity, so that you only publish the website from the stable branch. Blah again 😂 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Blah indeed. Let's just go with it as it is, I think it's good enoigh? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yolo. We might end up adding a couple more of these as the complaints roll in 😂 thank you so much for your work on this. |
||
} | ||
|
||
import autoImport._ | ||
|
@@ -123,7 +130,9 @@ object TypelevelVersioningPlugin extends AutoPlugin { | |
if (isSnapshot.value) version += "-SNAPSHOT" | ||
|
||
version | ||
} | ||
}, | ||
tlLatestVersion := currentRelease.value, | ||
tlLatestPreReleaseVersion := currentPreRelease.value | ||
) | ||
|
||
private val Description = """^.*-(\d+)-[a-zA-Z0-9]+$""".r | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shoot, still not quite right 😂 I thought this was using
version
in here, but you are right that it's not. Sorry, I was confusing with the change I made in #282 which does useversion
.So as it's currently defined, even if you've bumped your base version, if you haven't actually tagged anything with that new base version then it will still use whatever the latest tag is under the old base version. I guess this makes sense. But, now to explain it 🤔 tl;dr we do some blackbox heuristics to get you a sensible number, take it or leave it 😛