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)