Hyphen and Tilde

[EddieGarmon]

are only used for prerelease identification.

Closes #145 - introduce tilde as an alternate prerelease marker for *nix support (incremental addition)
Closes #147 - remove hyphen as a valid identifier character (breaking change)

[crazedsanity]

👍

[FichteFoll]

This is personal opinion.

I'm more positive on using ~ for metadata instead of pre-releases (and potentially + for post- or dev-versions), but that's a different breaking change. The - hyphen resembles a minus in many situations and this shows that the initial version identifier (1.0.0) is subtracted by something (1.0.0-1). (I know this doesn't really work well with increasing pre-release versions having higher precedence despite the subtrahend increasing, but you get the point.) The same could apply to +.

Other than that, I agree with #145 (comment).

[jaapie]

Tilda is a typo. It should be Tilde.

[jwdonahue]

This is a breaking change and should not even be included in 3.x.x if it ever comes to pass. Please close/cancel this PR at your earliest possible convenience.

[FichteFoll]

Why should a pr be closed if it is incompatible with the current major version?

[jwdonahue]

@FichteFoll, apologies for being so terse. It was getting late I was trying to complete reviews of all the PR's in the queue. Why should this be closed?

• Nearly doubles the number of test cases that packaging tools must run to cover the full spec.
• No road maps for maturing the existing standard, or evolving future standards.
• No maintenance branches for earlier versions and no development branches for vNext or beyond.
• My impression of a review of a large sample of the issues up to this point, is that version 3.0.0 is a long way off. There seems to be a strong inclination to maintain stability, to the point that even simple non-breaking changes, with obvious benefits to the clarity of the spec, have not led to a 2.0.1, much less a 2.1.0 update of the spec at semver.org, since when? At least three years?
• Aliasing prerelease tag prefix (hyphen) with a tilde removes that symbol from possible other uses, such as additional new fields or usage in mappings from SemVer <=> Other formats such as file systems and packaging tools.

On that last point, consider file systems or packaging tools that do allow the hyphen to be used as specified, but do not allow the plus symbol or its escape code &#43. I know of one tool with ~10K users that uses the tilde in place of the plus symbol when storing versioned collections of build tools in the cloud. All dots are converted to forward slashes making it very simple to iterate over all package names with a given prefix, such as 1.0.0-a (contains .dev, .nightly, etc.) for instance. Users can use the tool to run queries that result in the original SemVer strings being displayed or they can use the cloud service to browse through the storage system. That later use would be more complicated if the standard overloaded any of the field prefixes.

[jwdonahue]

I basically think that aliases should be left up to tool designers, not built into the spec.

[jwdonahue]

I recommend asking your package providers to fully support SemVer, rather than tweaking the spec.

Things have changed since you posted the PR. Please see the CONTRIBUTING.md file. In order to get a change committed to the spec, you must first convince a majority of the maintainers to implement your proposed changes, as experimental features.

Good luck with that!

[isaacs]

Both of these are breaking changes.

[EddieGarmon]

Adding an alternate unused character #145 is not a breaking change

[isaacs]

Yes, it is a breaking change. It will require that any existing uses of the ~ character in semver contexts be evaluated for compliance, and makes 1.2.3~4 a valid semver whereas before it was not.

This change in the spec, if implemented, will potentially require that consumers of those implementations change what they're doing. That's what a breaking change is.

If implementers want to have a mode or option to support a ~ instead of -, or make the - optional, then that's their prerogative. Node-semver supports a "loose" mode to allow things like 1.2.3foo instead of 1.2.3-foo.

[EddieGarmon]

This is not a breaking change in the spec at all. ‘~’ is not used at all currently.

If any implementation used it, they did so outside the spec. That is unfortunate, but not our problem.

[isaacs]

This is not a breaking change in the spec at all. ‘~’ is not used at all currently.

The breaking change is making a string that previously wasn't a valid SemVer into one that is.

~ wasn't just "not in the spec". It was excluded from it. So any implementations that rely on ~ being a SemVer delimiter or range will have be changed to accommodate adding ~ to the spec.

Let's say that we call it a non-breaking change. Any implementation that claims to implement or be compliant with "SemVer 2.x" will now be lying. This change would require consumers to re-evaluate (and potentially change) what they're doing, that's what a breaking change is.

I'm not saying it's a bad idea. Just that it is certainly a SemVer-major change.

One approach that would mitigate the downstream changes required would be to add an alternate mode (or perhaps several), with guidance to implementors suggesting what to do when parsing and re-encoding in those modes. However, support of these alternate modes should not be considered a requirement of compliance with SemVer 2.1 (or whatever).

There are some instances of this already in the wild.

Is there an implementation yet that can (or should) support this type of mode? I'd be happy to add ~ prerelease separator support in node-semver if that's helpful. But it would probably best if it was added to whatever SemVer implementation you're using today where you run into this issue.

[steveklabnik]

If any implementation used it, they did so outside the spec. That is unfortunate, but not our problem.

Without getting too into the weeds here: from my perspective, at least, the goal of spec changes right now is to clarify things for implementations. If a big implementation has a practical issue dealing with a spec change, that is our problem.

(I am not actually sure I agree with isaac that this is a breaking change, but haven't had the time to think through the details, I only want to respond to the comment about implementors.)

[EddieGarmon]

If any implementer of any specification “extends” that spec with custom additions on top of the spec, they are own their own when the specification get updated with a conflict to their extension.

It is not ever a concern of the updated spec, but of the people that extended it.

By the same count, if I were to create in code a set of extensions to an API I am consuming in a project, and the next version of that API added similar but different additions, is that a breaking change on their API because of what I did?

[steveklabnik]

I understand this viewpoint. What I am saying is that I disagree with it, in this specific instance.

The semver spec is not useful if it does not describe the actual implementations. A theoretical spec that isn't actually used isn't worthwhile.

[EddieGarmon]

After writing specs for SAE and ETSI for years, the thing that stands out most to me, is that you do not concern yourself with implementations, other than a reference.

[isaacs]

Look, bottom line, if we said we're going to start allowing a character that isn't currently allowed in the spec, that's a breaking change. It means that implementations that are 100% strictly compliant with SemVer 2.0 are not compliant with the SemVer spec that has that change. Maybe the change is good! But a change like that is properly SemVer 3.x, not SemVer 2.x.

Consider if we decided to allow any unicode characters in prerelease tags, or specify the main tuple with hexadecimal characters so that 2.AF.3 was a valid version. That would be a breaking change, because something that wasn't valid before is now valid. The effective "API surface" of a specification is the way that it defines what is allowed and what is not allowed. A non-backwards-compatible change to that surface is a breaking change.

If an implementation supports extensions to the spec, which are not specified, and a future clarification or update to the specification breaks those extensions, then yes, that's the implementor's problem, not ours. Propose a clarification or extension that makes node-semver's loose mode no longer "valid", and I'll happily put aside that consideration. After all, it's not strictly "valid" anyway.

I do think that it would be good to explicitly document some useful extensions (such as using ~ instead of -, or loose mode for backwards support of SemVer 1.x, or git-describe style numeric prerelease tags like v1.2.3-1-0bad1de4 that are higher precedence than their unadorned tuple) with guidance for implementors who can then add a "deb/rpm mode" for parsing and encoding, while noting that these extensions are not required for an implementation to be considered fully compliant with the SemVer specification. Then we could implement a deb/rpm mode without having to feel like we're going off book.

Done in that way, I'd call it a candidate for SemVer 2.1.

[alexandrtovmach]

Closing & re-opening to trigger CI

[EddieGarmon]

@isaacs I will concede that to you. So maybe we really need to start a 3.0 dev and put there ideas to it.

[isaacs]

@EddieGarmon I might've talked myself into the mid-way position while trying to talk you out of yours 🤣 I think specifying some "known useful" non-normative extensions to the specification might be really valuable, so at least we can all be on the same page about how exactly to do ~ or loose mode. Could be a good stepping stone to play-testing some ideas for a SemVer v3 specification.

Honestly, I'm not sure SemVer v3 is even such a great idea. It's so wedded to the interface layers of the module communities using it that even clearly valuable improvements carry a lot of risk and cost to adopt. If we do bite the bullet and go for a v3 spec, it might be wise to only have it expand to handle cases in the wild, such that any valid v2 SemVer is also a valid v3. That'd pretty significantly limit what we could consider (eg, the proposed restrictions on - would be out of bounds), but it'd also avoid a situation where we bump the major on the spec, and no one can ever actually use it.

So, what I'm suggesting is something like:

• SemVer 2.1:
  • Here's how ~-prerelease works. Parse with ~ instead of - as the prereleasae prefix, and when encoding in this mode, use ~ instead of -, and strip any - from the prerelease tag. Implementations may implement this mode, but if they do implement it, they must do it such and such way.
  • Here's how loose mode works. Loose mode must be input only, and encoding SemVer strings must be done in strict mode. Implementations may implement loose mode, but if they do so, they must follow this spec.
• SemVer 3.0:
  • If a SemVer version string has ~ in such and such spot, then it must be treated as a prerelease prefix, but encoding may be done with either ~ or - as the prerelease prefix.
  • SemVers that are valid loose mode version strings must be parsed in loose mode, but encoding must be done in strict mode.

Or something like that.

I've been meaning to write up a spec for ranges as well, could get that started at least with a straw proposal for what node-semver and the semver crate implement. There'll be some discussion required to get that into a reasonable shape, I'm sure. That could also be a v2.1 enhancement, since it truly is strictly additive and isn't going to change anything that's in the spec today.