-
Notifications
You must be signed in to change notification settings - Fork 9
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 always building -SNAPSHOT
versions when not building with a special flag
#90
Comments
Interesting. Can you describe the the requested feature in the form of current vs requested behavior? I want to make sure I understand it. Thanks for reporting! |
Sorry about the ramble, I wrote all that just before going to bed 😄. What currently happens: What I would like to happen: |
Hey @magneticflux- Interesting use case. I think the The incrementing bit is a little tricky. Some options:
Thoughts? Other options? |
I think When building a version on a feature branch, the patch number is incremented for each commit. However, as soon as that feature branch is merged, the patch number goes back to +1 for the merge commit. An example:
If I'm understanding the plugin behavior correctly, this leads to situations where a feature branch from the past could have built a version that a different branch now builds, and there's no way to tell which branch a given version was built from. I think this could be a big problem down the road if someone were to just discover a jar file somewhere and not know where it was built from. To resolve this, I think the plugin needs some understanding of if it's on a feature branch or on the main branch. A regex match on a branch name could indicate being on a "main" branch (for me |
The reason we count the commits is to allow "concurrent PR merges" that trigger releases. If you close 3 PRs at the same time, you'll get 1.0.1, 1.0.2, 1.0.3 (assuming that previous was 1.0.0).
I think that's normal ;-) Version number does not contain this information. (you could add it will little effort |
I totally agree, this works great for counting merge commits! I just don't think it makes sense to count non-merge commits on non-release branches the same way. I'm also skeptical if people actually use the generated version numbers on non-release branches (this project at least doesn't do anything with them since releases are only pushed on I've looked at Axion, but it seems to have pretty poor support for Kotlin DSL which is a personal must for my new projects (allegro/axion-release-plugin#285). I also feel it's a little further from the "sensible defaults, batteries included" approach that I like with this plugin (of course, I'm biased by my own opinions of "sensible" 😉).
I also agree with this to some extent: it's definitely not expected to be able to pinpoint what branch, commit, and VCS history went into an artifact. However, in this instance I think it's really useful to be able to immediately see |
@magneticflux-, it's been long, I'll close the ticket. Reopen if needed! |
My workflow is as follows:
release/xyz
anddevelop
.develop
tofeature/xyz
.feature/xyz
intodevelop
.develop
intorelease/xyz
.I already publish builds from
release/xyz
branches to various maven repos and Github Releases using the Shipkit plugins.I would like to expose snapshot builds from
develop
andfeature/xyz
branches somewhere (Maven, Github Actions build artifacts, etc.). Additionally, local builds (potentially having non-committed changes) should by default be marked as snapshots to distinguish them from reproducible builds on CI. I personally like having Git tree status included in the version like is done here: https://github.com/CaffeineMC/sodium-fabric/blob/68ca12bcbd57eddfaf47aa66492464540c2c7581/build.gradle#L75-L97This would be extremely useful for simply linking development builds to users in order to get feedback on issue fixes quickly. Examples of this workflow can be found in one of my repos here: https://github.com/magneticflux-/fabric-tree-chopper
#37 and #77 are similar to this, but #37 requires an override for snapshot builds rather than the reverse and #77 requires
-SNAPSHOT
in theversion
property to be set (if I'm reading the PR's code correctly: https://github.com/shipkit/shipkit-auto-version/pull/78/files#diff-b565cb97994bdd103d4038e053277da3b27f44237fcc958388e286ec930caa1aR112-R114)The text was updated successfully, but these errors were encountered: