Skip to content
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

Closed
ccharles opened this issue Oct 25, 2022 · 5 comments
Closed

Consider using semver-compatible version specifiers for LTS releases #1155

ccharles opened this issue Oct 25, 2022 · 5 comments

Comments

@ccharles
Copy link

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, and 1 do not match versions 1.4.4-lts.1 or 1.4.5-lts.1:

image

I think the -lts.1 suffix is understood as a prerelease. This has two consequences:

  1. NPM requires that an exact version specifier be used:

    image

  2. These versions sort before the non-LTS tags e.g.:

    image

    image

@LinusU
Copy link
Member

LinusU commented Oct 26, 2022

The 1.4.5-lts.1 version contains breaking changes which is why we haven't released it as just 1.4.6. The breaking change is that support for older versions of Node.js is now broken. If anyone contributes a patch so that we can address the security issue without breaking compatibility I'll be happy to merge and release that as 1.4.6!

@LinusU LinusU closed this as completed Oct 26, 2022
@ccharles
Copy link
Author

@LinusU, great, thanks for responding!

In that case, "LTS" feels like a strange name for these releases. Would -beta or -pre or something be more intuitive?

@LinusU
Copy link
Member

LinusU commented Oct 26, 2022

I'm not sure about -beta or -pre, since this is neither a beta or a pre-release. If you have any other suggestions I'm open to hearing them, but -lts has been in use for a while now and I'm not sure that it would be worth the churn...

@nbkhope
Copy link

nbkhope commented Nov 24, 2022

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.

@bwobbones
Copy link

@LinusU can you link the issue that describes the breaking change?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants