>My package really does depend on the latest patch release!

> Even in the event that your packages code is only correct with a specific patch release, I still think its wrong to put that version in the go directive unless it cannot be compiled with any other version.

I'm not a go user, but this strikes me as an over-reaction. If your code is only correct with a specific patch release, then it really is your business to make that so. If someone downstream wants to use library_method_broadly_correct and not library_method_correct_only_with_latest, then downstream should patch your source to allow them to do something unsupported. That becomes their problem. If this is likely to be a significant problem that will affect many users, then this is a codesmell warning you that you've probably got two libraries which you're just jumbling together into one: the solution isn't to falsely gate a safe function behind a high dependency version, nor to falsely release a function to people who can't use it safely, but to publish each with its own requirements expressly stated.

▲

Aurornis 2 days ago | parent | next [-]

That part struck me as well. I agree with the premise that the field should represent the minimum supported version, but I don’t understand the argument that it shouldn’t be set to the minimum supported version that works. That’s the point of a minimum supported version field.

▲

EdwardDiego 2 days ago | parent | next [-]

I'm struggling to think of a scenario where bumping the minimum Go version you support would be essential to fixing a bug though, because that would imply a massive Golang bug and AFAIK it's pretty stable.

And if it was a massive Golang bug, then maybe everyone needs to upgrade anyway.

	▲	billsmithaustin 19 hours ago \| parent [-]
		Or not a Golang bug at all but rather a new Golang feature that the developer chose to use rather than trying to be backward compatible with some older Golang versions.

▲

boomlinde 2 days ago | parent | prev [-]

I think "minimum supported version" is a specific enough qualifier on its own. Whether or not it works on my favorite earlier version, actually supporting that version and making sure to maintain compatibility is more work for the maintainer.

▲

howardjohn 2 days ago | parent | prev | next [-]

I can admit that part was maybe a bit extreme :) fortunately in practice this would be a pretty rare situation IME due to how compatible Go is across versions.

(Blog author)

	▲	frizlab 2 days ago \| parent \| next [-]
		I’m afraid setting a version lower than the one you’re using means you have to setup a CI of some kind to verify compilation does indeed work for previous versions of go. Maybe that’s why some author do not bother and put the version they are using (though I do agree it is a bad practice indeed).
	▲	vogelke 2 days ago \| parent \| prev [-]
		Thank you for this article. If I want to be told when to upgrade, I know where to shop, i.e. Bill's Bloatware in Redmond.

▲

websap 2 days ago | parent | prev [-]

Yeah, sounds like a skill issue.