mirror of
https://github.com/semver/semver.git
synced 2026-07-11 05:12:48 -05:00
[GH-ISSUE #942] Questions about skipping versions #6576
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#6576
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @User670 on GitHub (May 5, 2023).
Original GitHub issue: https://github.com/semver/semver/issues/942
@ljharb commented on GitHub (May 5, 2023):
Yes, and no, is my understanding.
@JohnTitor commented on GitHub (May 5, 2023):
I haven't come up with the use case, but I agree with @ljharb.
@jwdonahue commented on GitHub (May 14, 2023):
Given that you are under no obligation to publish any package indefinitely, and there are some perfectly legit reasons to remove a version from public view, the version history as seen on a public feed for a project may indeed have gaps in it.
Here's the scenario I think legitimately applies in your case:
I don't think the public cares that they never had access to a 2.0.0.
So ya, you can skip versions in your release or any other feeds. It's up to you which versions are maintained for public access. Just don't ever publish two different packages with the same version number but different content. If 2.0.0 was built and wound up being passed-over for 2.0.1, you can't build a new 2.0.0 and release that. Package versions have a habit of finding there way into the wild, even if they were meant for internal use.
@jwdonahue commented on GitHub (May 14, 2023):
Here's what the spec actually prohibits:
1.0.0
1.0.1
1.0.2
2.0.2
2.1.2
3.1.3
4.1.3
In other words, the fields should not be treated as counters for breaking changes, features and patches. Mind you, it's impossible for anyone to tell from a feed list whether you're honing to SemVer or not. That sequence might appear for a product form a publisher that just has extremely bad quality controls and had to remove a LOT of versions from the list.
Your automation should follow the rules, your common sense should determine whether any particular version of your automated output is actually published to your feed.
@ljharb commented on GitHub (May 14, 2023):
Of course you can build another 2.0.0, only releases are immutable.
@jwdonahue commented on GitHub (May 14, 2023):
Very bad idea. I've worked for a company that had hundreds of integration branches and associated automated builds, we wound up ensuring there could never be two with the same version number on them, even if we failed on one pass and rebuilt against the same content hash.
It's probably better today, but back then, too many tools embedded local paths, builders user name, dates, times, GUID's and other randomness. You also have to factor in tool patches/upgrades between builds. When presented with a pair of packages who's contents are different but they have the same version numbers on them due to poorly designed automation, which one is the correct v X.Y.Z ?
No, just don't ever do that. Like I said, packages have a tendency to find their way into the wild, especially when it comes to the "final" cuts that look like they are releasable based on the version number.
@ljharb commented on GitHub (May 14, 2023):
That’s why you use commit hashes and not version numbers on builds; the version numbers are only for the release.
@jwdonahue commented on GitHub (May 14, 2023):
I agree it's pretty useless to put version numbers in the repo when you have a perfectly good hash, but even if you think your building the same thing, there's a pretty good chance you can't build the same product twice in a row. Even if all of your tools emit deterministic results, you still have the OS/tool-chain upgrade issue to contend with.
And then there's the many unwashed DevOps systems that lack the ability to include every single detail about their configuration in the repo from which the product was built and the fact they build in a cloud where you may have little control of the build environment.
Better/easier to design automation that is guaranteed to produce globally unique SemVer strings.
@jwdonahue commented on GitHub (May 14, 2023):
I did a lot of work at Microsoft to move the needle towards deterministic tools, but even if we had succeeded at that (we didn't, but maybe that's changed), analysis revealed that even if we tried to preserve the machine states (Motherboard, OS patch level, etc), we'd then run into situations where simply applying power to that preserved configuration would be a violation of current security policies at some point out in the future.
It's not a hill any of us wanted to die on. Much easier to ensure you never emit the same version string twice.
@ljharb commented on GitHub (May 14, 2023):
I’m not sure how that’s relevant - I’m still talking about unique versions, I’m saying that “the build” doesn’t get one, it gets a hash - only releases get versions (in the repo, and as a tag)
@Kellybaines commented on GitHub (May 14, 2023):
JPXB18271 my winnings kelly Baines England
@jwdonahue commented on GitHub (May 15, 2023):
It doesn't really work that way in practice. My experience has been you get a build, you test it, you package it (versioned output), then you do some final tests on the package content, and wait for executive signoff, then you either release that package as-is, or you don't. Now you've built one, you should never reuse that version number again, doesn't matter whether you delivered it (deliberately) to the public or not. You produced an artifact that includes a version number, that number is burned forever or you risk having multiple package contents with the same version number on them (bad).
@ljharb commented on GitHub (May 15, 2023):
That's certainly a position to take, but the only things that are burned forever in my experience are things that somebody could have possible consumed. Anything else is just wasteful.
@jwdonahue commented on GitHub (May 15, 2023):
Some organizations will have different issues/requirements. A good bit of my experience the past 20 years was with Microsoft, where you have a lot of parallel processes, producing many artifacts that have the same name, that can be accessed by many people (tens of thousands), you pretty much have to do a lot of internal publishing and you don't ever know which versions of what are going to wind up being released to the public , officially or otherwise. So you get in the habit of generating unique version strings for ever build artifact. Of course, they don't always use SemVer for many of their products, but the issues remain the same.
@jwdonahue commented on GitHub (Aug 11, 2023):
I think this question has been answered. @User670, if you have no further concerns, please close this thread.
@JohnTitor commented on GitHub (Aug 12, 2023):
I'm going to close, feel free to reopen or create a new issue if you still have a question!