-
Notifications
You must be signed in to change notification settings - Fork 67
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
Confirm the order of prereleases #859
Comments
I think we should follow semver rules. Semver has clear rules for precedence of prerelease tags. If you want prerelease identifiers to be compared numerically, they must be separated by dots, that is:
For timestamps, if they are in the YYYYMMDD format, they are ordered the same lexicographically and numerically. |
Currently, timestamps are represented in the Unix form, so it should work until somebody (or a buggy CI job?) accidentally posts a shorter timestamp.
I understand that it should work out of the box, right? We shouldn't need to patch the library code. -- I'm wondering if we need to apply a patch to ensure the correct order of tags (beta/rc... preview). |
I made more experiments to learn about the dotted approach. We need to remember that if the package versioning pattern switches from This is the pattern that is currently applied for the APM package: https://epr-v2.ea-web.elastic.dev/search?prerelease=true&package=apm. We don't plan to mix prerelease tags, so I guess that this form is safe. |
Yes, this should work with current semver library. If not, this is a bug in the library.
With current labels and ordering (1.0.0-alpha < 1.0.0-beta < 1.0.0-preview < 1.0.0-rc < 1.0.0), it seems that the only problem is preview, maybe we should use the more industry-standard "alpha" instead of preview. Or completely remove the "preview", 1.0.0-1659529701 would be lower than any prerelease with letters, and would be still clear that is not an stable version.
Well, or until timestamps need a new digit to be represented, but this won't happen till UNIX time 10000000000, a.k.a. November of 2086 😃
If a project wants to change this, I would consider doing it after a version change, so prereleases are consistent inside a version.
Yes, this looks safe, at least till 2086 🙂 But in any case it may be worth to change to the dotted form on the next version, to be more explicit on the numeric order of the versions. Or to remove the "preview" part, as commented above. |
While working on elastic/apm-server#8491, I found an interesting problem: are all prerelease tags comparable?
The package-spec allows for defining the prerelease part as tag + timestamp. Which rules should EPR follow to figure out which revision is the newest one.
Few "tricky" comparisons:
8.5.0-preview-1111111111111
vs8.5.0-preview-2111111
8.5.0-preview-1111111111111
vs8.5.0-beta-1111111111111
I guess that we have to apply more rules (first thoughts below) to the IsNewerOrEqual function like:
BTW the APM team selected the
preview
tag as it seemed to be the most accurate for them.Feel free to chime in, @jsoriano @mrodm.
The text was updated successfully, but these errors were encountered: