chore: retract v1.13.14-0.1.0-rc.1
#81
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The pre-release portion of semver is everything after the `[patch]-` hyphen, with every part being dot-separated. This causes `0.1.0-rc.1` to be considered higher than `0.1.0.rc-2`, which used the corrected format. In the future we SHOULD actually use `.rc.[numeric]` to properly order release candidates numerically by their final part (mea culpa).
ARR4N
requested review from
a team,
darioush,
ceyonur and
michaelkaplan13
and removed request for
a team
darioush
approved these changes
Dec 3, 2024
ARR4N
added a commit
that referenced
this pull request
Feb 14, 2025
## Why this should be merged Our initial release tags weren't well-formed for our needs. Although the format was locked in in #81, I still stuffed up rc2. With the upcoming rc3 release, we want to ensure that Go tooling picks it up as the latest, which requires retracting rc2 as its format means it will take higher precedence. ## How this works `go.mod` `retract` ## How this was tested n/a
ARR4N
added a commit
that referenced
this pull request
Feb 17, 2025
## Why this should be merged Both #141 and #81 attempted to fix my lack of planning with release versioning however Go modules [require a higher-precedence version for retract statements to be honoured](https://go.dev/ref/mod#go-mod-file-retract:~:text=The%20new%20version%20must%20be%20higher%20than%20other%20release%20or%20pre%2Drelease%20versions%3B%20that%20is%2C%20the%20%40latest%20version%20query%20should%20resolve%20to%20the%20new%20version%20before%20retractions%20are%20considered.). The only way we can get that with our [versioning rules](https://github.com/ava-labs/libevm/blob/32e7dafe1c176ec1ef447119a2d996210b877864/params/version.libevm.go#L30) is to bump the minor version. This will negate the need for explicit retraction so I'm removing it as a cleanup. ## How this works n/a ## How this was tested [Effect of bumping minor](https://semvercompare.azurewebsites.net/?version=1.13.14-0.1.0.rc.3&version=1.13.14-0.1.0.rc-2&version=1.13.14-0.1.0-rc.1&version=1.13.14-0.2.0.rc.1): 
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why this should be merged
I messed up the format of
rcversion tags, resulting inrc.1being considered a later version thatrc.2.How this works
The release tagging pattern that includes a combination of
gethandlibevmsemver triplets (e.g.1.13.14-0.1.0) doesn't work well with extra identifiers likercbecause more pre-release identifiers (those after-) take higher precedence if all those before them match. We therefore have to use areleasesuffix ("release" > "rc"in ASCII).This all became too much to expect to be done manually so I chucked it in code instead.
How this was tested
Unit test demonstrates expectation of version ordering.