![]() Yeah, I often prefer, when possible, to automate in CI dumping the git describe output to a. Only if you make new commits and/or have uncommited changes do you get a different string without having to commit anything. If you build the tagged release in a clean repo, the string will just be the tag. You can incorporate this sort of identifying string at build time nothing is checked in. If there are no uncommited changes, then -dirty is omitted, and if there are no commits since the tag (we are at the tagged commit), then the count of commits and hash are omitted. It will produce a string consisting of the most recent tag, the number of commits since that tag, a portion of the hash and the word "dirty", all separated from each other by a dash. ![]() It could be from the git sha, plus some indication of whether it was a dirty state or exactly that git sha. What you can do is incorporate some build identifier into local unreleased builds. Unreleased software doesn't require a version number at all. Why tag the same thing with two different versions? You're only inviting merge conflicts with changes like this. The only content which is different is is the version number you're effectively tagging the same software with an incremented version. The downside is that you need a commit which serves no purpose other than to increment the number. I guess one is it requires you to have all tags locally which is a silent failure mode when you don't and disallows shallow clones. This article advocates against it but doesn't give the reason. I've seen some advocate for not keeping a version in source at all. Will the next release bump the pre-release version, patch, minor, or major?Ī downside to keeping either last version or next version is if someone builds from master, the bug report could be confusing unless you include the git hash (and whether the repo was dirty). The "next version" is just speculation. This is why the default changed in cargo-release. (Rust specific) It makes it harder to patch a registry dependency with a git dependency because the versions will never align. Easier to detect when a change occurred since the last release When I took over cargo-release, this was also the default though not anymore. This is what I was used to at a prior day job (another one just didn't keep a version in source).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |