-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
Support Mill 0.11.0-M1 #36
Conversation
Hey! Thanks for the pr! Ideally I'd like to include a stable release if I was going to release, but I'm also comfortable merging this, which will produce a snapshot that you could use. Would that work for you? As I'm assuming you're wanting to use this with something that is using 0.11.0-M1 😆 |
I'm not waiting on it, so no worries :) |
Not so sure about that. We have a not so small backlog and we should try to bring as much as possible into I try to publish a new |
I was referring to a stable version of |
Oh. 😳 I already published a snapshot supporting Mill 0.11.0-M1: https://repo1.maven.org/maven2/de/tototec/de.tobiasroeser.mill.vcs.version_mill0.11.0-M1_2.13/0.3.0-7-8f12c7/ That's the one already used in this PR. I didn't plan to make a numbered release of it, as it is already accessible from Maven Central. Do you need one? |
If we think it's ok for this plugin to depend on a snapshot release of it, it's fine for me :) |
I guess I have opinionated thoughts about snapshots. Mainly if we're ok releasing and having others depend on them, why not just make it a stable release? I can merge this, but my snapshot will go into sonatype snapshots, which means you'd need to add another resolver and doing that for plugins is a bit of a hassles since you have to add a I typically like to avoid relying on SNAPSHOTs for stable releases, but I see there is hardly anything that's changed in the commits up until this, and I know @lefou takes compatibility seriously 😆 . |
So, technically, mill-vcs-version-0.3.0-7-8f12c7 is a proper release. It's on Maven Central releases repository, and as such rather immutable. The version is also unique. The only thing that's different from other "official" releases is, that it is not tagged with a git tag and it has no dedicated changelog entry. But it already has the (start of the) commit hash in it's name, so it should be still reproducible. So it depends where @ckipp01 cut the line between "snapshots" and "releases". Is it semantically (Maintainer created a tag) or technically (the (probably not unique) location of the binary artifact)? Because of no other changes beside some library dependency bumps, I find a new release kind of overkill. If it would be technically easier, I would in fact try to release the already released version 0.3.0 against the new Mill API, but it's simply not worth the efforts to do it, given the fact, that there will be more of these |
No worries at all. I just released Thinking about it, maybe both of us should have used an |
I used a snapshot release of
de.tobiasroeser.mill.vcs.version
, you may want to wait for the next stable.