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

cmd/go: document best practice for “postdated” requirements #26150

Closed
bcmills opened this issue Jun 29, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@bcmills
Copy link
Member

commented Jun 29, 2018

Summary

I want to express a dependency on an unreleased upstream fix.

I think the right way to do that is to require the version expected to contain the fix and replace it locally in a pre-release version of my module.

I'd like to confirm that or find a better alternative.

Details

(This issue is motivated by thinking about some edge cases in https://golang.org/cl/121000.)

Suppose that own module example.com/a, with the following module definitions:

module example.com/a

require (
	example.com/b v1.0.0
	example.com/c v1.0.0
)
module example.com/b

require example.com/d v1.1.0
module example.com/c

require example.com/d v1.2.0

I discover a bug in d v1.2.0 and contribute a fix. The module maintainer decides that it's too invasive to issue as a patch release, and plans to release it (along with a bunch of other changes) as v1.3.0 in a few months. In the meantime, they don't want to clutter their repository with prerelease tags for every individual fix going into v1.3.0.

Now I want to advertise the fix so that my users will test against it. My users (and their users, and so on) will have to add their own replace directives if they want everything to work, so I'll tag my fix as a pre-release (say, example.com/a v1.1.0-alpha1): that way they'll find it if they're actively looking for bug-fixes, but their build won't break if they just run vgo get -u.

I want my pre-release to fail to build before d v1.3.0 is released (so that my users know to add the replace directive), but to build successfully (without waiting for me to add another tag) if my users upgrade to the actual d v1.3.0 when it becomes available.

That suggests that my go.mod for a v1.1.0-alpha1 should look like:

module example.com/a

require (
	example.com/b v1.0.0
	example.com/c v1.0.0
	example.com/d v1.3.0
)

replace example.com/d v1.3.0 => example.com/d v0.0.0-YYYYMMDDHHmmSS-HHHHHHHHHHHH

Is that the best way to address my use-case?

(CC: @rsc @myitcv)

@gopherbot gopherbot added this to the vgo milestone Jun 29, 2018

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2018

SGTM

@bcmills bcmills self-assigned this Jul 4, 2018

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2018

This is "postdating" not "backdating".

@rsc rsc changed the title x/vgo: document best practice for “backdated” requirements x/vgo: document best practice for “postdated” requirements Jul 10, 2018

@rsc rsc modified the milestones: vgo, Go1.11 Jul 12, 2018

@rsc rsc added the modules label Jul 12, 2018

@rsc rsc changed the title x/vgo: document best practice for “postdated” requirements cmd/go: document best practice for “postdated” requirements Jul 12, 2018

@gopherbot

This comment has been minimized.

Copy link

commented Jul 17, 2018

Change https://golang.org/cl/124515 mentions this issue: cmd/go/internal/modfetch: move to new pseudo-version design

@gopherbot gopherbot closed this in 9430c1a Jul 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.