-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Consider using semver-compatible version specifiers for LTS releases #1155
Comments
The |
@LinusU, great, thanks for responding! In that case, "LTS" feels like a strange name for these releases. Would |
I'm not sure about |
I'm sure you must have had some reason to do it, so pardon my comment. If you have a breaking change, the major version should be bumped. If you are afraid of conflicting with an existing development of the new major version, then in my opinion the breaking change should not have been made for the v1 series. An idea, but it might be some effort: that future conflicting version could be bumped one more number; so assuming it's v2, the new v2 would be v3. If you do want to have future version development going on at the same time and doing breaking changes to previous versions, to avoid version problems like this in the future, I think the next version should not be a fixed number. You could have something like "next" tag or similar. The specific number is only given once you are ready for release. |
@LinusU can you link the issue that describes the breaking change? |
It appears that the latest LTS releases, which I understand to be extensions of the 1.x development line, are not compatible with semver as implemented in the NPM ecosystem.
Version constraints like
^1.4.2
,1.4
, and1
do not match versions1.4.4-lts.1
or1.4.5-lts.1
:I think the
-lts.1
suffix is understood as a prerelease. This has two consequences:NPM requires that an exact version specifier be used:
These versions sort before the non-LTS tags e.g.:
The text was updated successfully, but these errors were encountered: