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

Preparing a v2.0.2+incompatible pre-release to properly retract v2.0.1+incompatible #254

Merged
merged 2 commits into from
Aug 27, 2024

Conversation

AnomalRoil
Copy link
Contributor

@AnomalRoil AnomalRoil commented May 6, 2024

We need to issue a higher version tag which self-retract itself in order to retract v2.0.1+incompatible
I have chosen a pre-release v2.0.2+incompatible value so that it will still be possible to create v2.0.x versions in the future without conflicting with it.

After merging this, please tag the latest master with tag v2.0.2+incompatible and push the tag to github 🙏🏻

As per the Go spec:

To retract a version, a module author should add a retract directive to go.mod, then publish a new version containing that directive. The new version must be higher than other release or pre-release versions; that is, the @latest version query should resolve to the new version before retractions are considered
A version containing retractions may retract itself. If the highest release or pre-release version of a module retracts itself, the @latest query resolves to a lower version after retracted versions are excluded.

Copy link

welcome bot commented May 6, 2024

Thank you for submitting this PR!
A maintainer will be here shortly to review it.
We are super grateful, but we are also overloaded! Help us by making sure that:

  • The context for this PR is clear, with relevant discussion, decisions
    and stakeholders linked/mentioned.

  • Your contribution itself is clear (code comments, self-review for the
    rest) and in its best form. Follow the code contribution
    guidelines

    if they apply.

Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment.
Next steps:

  • A maintainer will triage and assign priority to this PR, commenting on
    any missing things and potentially assigning a reviewer for high
    priority items.

  • The PR gets reviews, discussed and approvals as needed.

  • The PR is merged by maintainers when it has been approved and comments addressed.

We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution.
We are very grateful for your contribution!

@AnomalRoil AnomalRoil force-pushed the retractproper branch 2 times, most recently from ee667cd to ba88ba7 Compare May 6, 2024 09:04
@AnomalRoil AnomalRoil changed the title Preparing a v2.0.42 release to properly retract v2.0.1+incompatible Preparing a v2.0.3-retract pre-release to properly retract v2.0.1+incompatible May 6, 2024
Signed-off-by: Yolan Romailler <anomalroil@users.noreply.github.com>
@AnomalRoil AnomalRoil changed the title Preparing a v2.0.3-retract pre-release to properly retract v2.0.1+incompatible Preparing a v2.0.2-retract pre-release to properly retract v2.0.1+incompatible May 6, 2024
go.mod Outdated
@@ -24,3 +24,5 @@ require (
retract v1.0.22 // old gx tag accidentally pushed as go tag

retract v2.0.1+incompatible // old gx tag

retract v2.0.2-retract // we need to use a newer version than v2.0.1 to retract v2.0.1+incompatible, but we can retract ourself directly once done
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI is failing with: go.mod:28: retract github.com/ipfs/go-ipfs-cmds: version "v2.0.2-retract" invalid: should be v0 or v1, not v2

It looks like this might be because we'd need to change the import path in this go mod file as well golang/go#35732 (comment). I haven't dealt with two many v2 modules like this before though so lmk if I'm missing something.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Side note: Does this need to merge into master or can this merge into a v2.0.2-retract-branch and be released from there?

Copy link
Contributor Author

@AnomalRoil AnomalRoil Aug 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this sadly has to stay in the go.mod for subsequent releases and cannot just be removed after tagging the higher v2.0.2-retract self-retracting pre-release, but not 100% sure.

@lidel
Copy link
Member

lidel commented Aug 6, 2024

Triage notes:

  • @AnomalRoil where does this problem manifest?
  • gx tags were created before modern v2 conventions were introduced and it may be tricky to fix, so we want to understand the priority here (creating dead v2 version only to solve low priority problem does not sound like a good play)

@lidel lidel added the need/author-input Needs input from the original author label Aug 6, 2024
@AnomalRoil
Copy link
Contributor Author

AnomalRoil commented Aug 14, 2024

Currently the Go ecosystems recognizes the v2.0.1+incompatible to be the latest release:
image

To properly retract a release you need to tag a higher version number tag with a retract statement for both.

See doc here: https://go.dev/ref/mod#go-mod-file-retract

The main goal being to allow people to use go get -u to update dependencies successfully, but tbh I'm not even sure the latest issue is related to this one:

$ go get github.com/ipfs/go-ipfs-cmds@latest
go: github.com/ipfs/go-ipfs-cmds imports
	github.com/ipfs/go-ipfs-cmdkit/files: cannot find module providing package github.com/ipfs/go-ipfs-cmdkit/files

@AnomalRoil AnomalRoil changed the title Preparing a v2.0.2-retract pre-release to properly retract v2.0.1+incompatible Preparing a v2.0.2+incompatible pre-release to properly retract v2.0.1+incompatible Aug 14, 2024
Copy link
Member

@lidel lidel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Triage notes:

@lidel lidel merged commit de1cb7f into ipfs:master Aug 27, 2024
9 checks passed
lidel added a commit that referenced this pull request Aug 27, 2024
tagging a release that includes go.mod with retraction
from #254
@lidel lidel mentioned this pull request Aug 27, 2024
2 tasks
lidel added a commit that referenced this pull request Aug 27, 2024
tagging a release that includes go.mod with retraction
from #254
+ go 1.22 version bump
@lidel
Copy link
Member

lidel commented Aug 27, 2024

Just for the record (cc @gammazero) this did not work because +incompatible is respected only if tag does not include go.mod:

$ GOPROXY=https://proxy.golang.org GO111MODULE=on go get "github.com/ipfs/go-ipfs-cmds@v2.0.2"
go: github.com/ipfs/go-ipfs-cmds@v2.0.2: reading https://proxy.golang.org/github.com/ipfs/go-ipfs-cmds/@v/v2.0.2.info: 404 Not Found
	server response: not found: github.com/ipfs/go-ipfs-cmds@v2.0.2: invalid version: module contains a go.mod file, so module path must match major version ("github.com/ipfs/go-ipfs-cmds/v2")

I've removed the tag since it is useless anyway and filled golang/go#69093 to remove broken version from x/pkgsite.

@AnomalRoil until upstream is cleaned up, as a workaround, you can run GOPROXY=direct GO111MODULE=on go get -u ./... to skip broken cache of x/pkgsite.

@AnomalRoil
Copy link
Contributor Author

AnomalRoil commented Sep 3, 2024

@lidel I suspect this did not work properly because you tagged v1.13 instead of tagging v2.0.2+incompatible and v1.13 < v2.0.2+incompatible as per semver.

Edit: reading the other issue, it seems that should work if we tagged v1.0.23 instead of v2.0.2+incompatible.
Meaning we need to retract v1.0.23 in the go.mod and tag it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/author-input Needs input from the original author
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants