doc/install: define minimum supported VCS versions #26746
Milestone
Comments
bcmills
added
the
NeedsDecision
|
Marking NeedsDecision to determine:
|
|
Maybe it would be sufficient to say "git version X or later is known to work" (taken from the oldest git version commonly used in tests), instead of figuring out and keeping track of the oldest suitable version? |
|
I would really hope that we work with whatever's in Debian Stable at least, which is currently 2.11.0: https://packages.debian.org/stretch/git |
|
Re @mostynb's point it's fine to say we need 2.5 even if 2.4 appears to work too. I also agree with Brad that essentially every git that's on a supported OS by default needs to work. That's been our practice to date. |
I think we all agree with that, but what does “supported OS” mean in this context? Our current definition for Go on Linux, according to the install page, is just a kernel version and a specific exclusion for CentOS/RHEL 5.x. That doesn't tell us which distros (and which versions of which distros) we should use to determine “every git that's on a supported OS”. To pick some examples:
|
|
The table at https://en.wikipedia.org/wiki/Git#Release says that Git 2.12 and older are themselves no longer maintained. (However, I'm having trouble finding any supporting documentation in the Git release notes or mailing list.) |
|
I suppose we could always vendor something like https://github.com/src-d/go-git . Not that I'm seriously suggesting that. When it comes to GNU/Linux distros, I suggest that we can plausibly take CentOS as the trailing edge. CentOS is specifically adopted by people who want long term stability and who don't want to hack on their systems. We have decided that CentOS 5 is too old, so let's take CentOS 6 as the oldest version we want to support. CentOS 6 comes with git 1.7.1. I have no idea what is involved here: can we support git 1.7.1 and later without unreasonable effort? |
It's probably inevitable that we go that route at some point. Maybe we should've from the beginning, in retrospect. If CentOS is an OS that people deploy to but don't develop on, perhaps we don't need to care about its git version, assuming they just get their packaged binaries via Docker or scp or whatever. But then one could make the same (incorrect?) assumption for Debian Jessie and Ubuntu 14.04 LTS, that people are more likely to deploy there than hack there themselves. But I just don't know if that's true. I wish we had an opt-in mechanism like Debian's popcon (https://popcon.debian.org/) to let us collect statistics from Go users on their OS/versions/tool versions. |
|
GitHub suggests using 1.7.10 in their help[*]: [*] https://help.github.com/articles/https-cloning-errors/ If a particular minimum tested git version is selected, perhaps it could be tested on a bot without distribution-specific git packages installed? That way the test would not be tied to a specific distribution, and any git version requirement changes would at least need to be made consciously from that point onward.
Sounds like an interesting side project, but would require some thought to avoid privacy/GDPR/etc issues. |
|
FWIW I don't think vendoring go-git is a good idea at all and I don't think it's inevitable we end up there. We should use the same VCS tools our users are, not ship our own slightly different tools with different bugs. Back before we started invoking git again we had a whole bunch of "git works why doesn't your tool?" kinds of bugs. I like that those are by definition gone. Maybe this thread is not really focused on the right thing. Maybe we should define which Linux distros we support and then it's implied which git versions we need to support. (And someone could figure out the exact implication.) Brad suggests:
Anything else? |
|
CentOS, as mentioned above. We have already chosen to not support CentOS 5, because the kernel is too old. What about CentOS 6? (It's clear from the number of bug reports we get about CentOS 5 that people who use CentOS do care about Go.) |
|
@ianlancetaylor, do you have any sense for whether people develop on CentOS vs just deploying to CentOS? If we only care that resulting binaries work well on CentOS 6, that's easier than making sure "go get" and friends work with old git versions. |
|
@bradfitz Yeah, I forgot about that question. I don't know. |
This feels like the most practical thing to do, not least because we can use a number of Docker/other images as test rigs, e.g. #26988 (comment).
I think this covers Travis and CircleCI. Put another way, I think it's worth making sure we have coverage of the major (to be defined) CI systems out there to ensure they are covered, and add their images/base images to the list if not. |
|
Even if there was to be a list of Linux distros enumerated, it seems there would still be a need to pick a minimum supported git version to handle Windows, Macs, etc.? It seems picking a git version would be more direct than picking a list of distros, including given the most immediate triggering event here seems to variability in git behavior across old versions. For a developer who is "stuck" with an older environment for whatever reason, it is probably easier to upgrade git than to switch distros or upgrade their OS, which means having the restriction based on git might be friendlier to Go users. That said, perhaps the conclusion ends up being both a git version and a list of distros get selected? If there is a list of Linux distros enumerated, I would hope it would be made extremely clear that it is not a contraction of where Go code can run once compiled but rather a contraction of where the Go tooling is supported. In terms of CentOS, I've definitely seen a common pattern of RHEL for production with CentOS for dev/QA (because very close to RHEL). However things are end up being characterized in terms of what is officially supported, a related question would be whether or not anything is validated, and if so, whether a failing result is a warning vs. error vs. ___. |
rsc
changed the title
rsc
removed
the
NeedsDecision
|
@bcmills can you describe what sorts of things break when using an older version of a VCS tool? Also would the go tool enforce or otherwise check the version and give a helpful error message? |
The typical failure mode is that we add some flag (e.g. to disable one of the many ways that user settings can leak in to the behavior of
If we know some version that we definitely don't support, we could emit a helpful error. |
|
As far as proposal process, everyone seems to agree we should do this - define which VCS we support. The exact details can be worked out as a regular issue. (See also #26746 (comment) above.) I have no idea if we use - from the go command - git options added since Git 1.7.1. One option is to say that CentOS 6 can be a deploy target but not a development target (at least for 'go get'). Can someone find out whether 'go test cmd/go/...' succeeds on CentOS 6 with git installed? |
I'll take a look. |
|
I spun up a CentOS 6 image and installed There were many failures, mostly related to Git commands. I'm doing to try from |
|
At |
|
I wanted to get a view of what might be a sensible cut-off for a minimum supported git version based on what modules users are using in practice. Based on spending a couple of hours on this today, my observations included:
Just because I found no complaints for a version range does not mean there were no complaints, but that sampling of results might suggest where the largest weight might be. I ended up reading a small number of older issues carefully, and skimming comments from a larger set of issues:
Here is a programatically generated list of mentions of git versions from comments in issues with the 44 mentions of git versions across 16 issues
This list was programatically generated, and then a small number of false positives were then manually pruned. |
|
While I am sure you don't want a bunch of people saying which distro they use, I will call out mine since it was questioned above. My company currently is developing and deploying on CentOS/Redhat 6, because of its long term stability. Also from a developers perspective, It would be a lot easier to see which OSes are supported period, rather than which is supported for development vs deployment. |
|
Change https://golang.org/cl/191978 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Aug 27, 2019
'git ls-remote' started recognizing the '--' separator at some point after 2.7.4, but git defaults to version 2.7.4 on Ubuntu 16.04 LTS, which remains supported by Ubuntu until April 2021. We added '--' tokens to most VCS commands as a defensive measure in CL 181237, but it isn't strictly necessary here because the 'scheme' argument to our template is chosen from a predefined list: we can safely drop it to retain compatibility. Fixes #33836 Updates #26746 Change-Id: Ibb53366b95f8029b587e0b7646a439330d759ac7 Reviewed-on: https://go-review.googlesource.com/c/go/+/191978 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
tomocy
pushed a commit
to tomocy/go
that referenced
this issue
Sep 1, 2019
'git ls-remote' started recognizing the '--' separator at some point after 2.7.4, but git defaults to version 2.7.4 on Ubuntu 16.04 LTS, which remains supported by Ubuntu until April 2021. We added '--' tokens to most VCS commands as a defensive measure in CL 181237, but it isn't strictly necessary here because the 'scheme' argument to our template is chosen from a predefined list: we can safely drop it to retain compatibility. Fixes golang#33836 Updates golang#26746 Change-Id: Ibb53366b95f8029b587e0b7646a439330d759ac7 Reviewed-on: https://go-review.googlesource.com/c/go/+/191978 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
t4n6a1ka
pushed a commit
to t4n6a1ka/go
that referenced
this issue
Sep 5, 2019
'git ls-remote' started recognizing the '--' separator at some point after 2.7.4, but git defaults to version 2.7.4 on Ubuntu 16.04 LTS, which remains supported by Ubuntu until April 2021. We added '--' tokens to most VCS commands as a defensive measure in CL 181237, but it isn't strictly necessary here because the 'scheme' argument to our template is chosen from a predefined list: we can safely drop it to retain compatibility. Fixes golang#33836 Updates golang#26746 Change-Id: Ibb53366b95f8029b587e0b7646a439330d759ac7 Reviewed-on: https://go-review.googlesource.com/c/go/+/191978 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
I've been thinking about this some more (in the context of #51253). Our own release policy doesn't determine which Go releases we support based on the (much older) versions that Linux distros choose to ship; we expect users to upgrade to a supported Go version if they run into trouble. Why should we not expect the same of the rest of their development environment? If users are running ancient versions of other parts of the development toolchain — perhaps with third-party security patches — can't they also run third-party-patched ancient versions of the Go toolchain to match? According to the table at https://en.wikipedia.org/wiki/Git#Releases (and supported by the tags shown at https://github.com/git/git), Git 2.17 received a patch release last year (2.17.6, tagged 2021-03-09), whereas Git 2.16 was last tagged over two years ago (2.16.6, tagged 2019-12-07). The 2.17.6 release was presumably for CVE-2021-21300, for which “the earliest impacted version is 2.14.2”. Since there were no mainline patch releases tagged for that issue for Git 2.14 through 2.16, I infer that those minor releases are no longer supported upstream. It has been suggested above that we use CentOS as the baseline for supported development environments, but it's not even clear to me which CentOS versions we should be considering. According to the CentOS wiki page, CentOS 7 stopped receiving “full updates” in August 2020, although it continues to receive “maintenance updates” through June 2024. And although @bradfitz filed #29114 to add a CentOS builder in December 2018, that still hasn't happened either — so actually supporting Go on CentOS 7 would require additional development overhead, since we can't just spin up a |
|
We do not currently have a builder with Git version 1, and the documentation at https://git-scm.com/docs seems to only go back as far as 2.10.5. Lacking both a builder and documentation, I plan to adhere to the following policy:
|
rsc
changed the title
|
just to note, [1] https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase |
scbizu
added a commit
to ezbuy/ezorm
that referenced
this issue
Feb 21, 2023
scbizu
added a commit
to ezbuy/ezorm
that referenced
this issue
Feb 21, 2023
scbizu
added a commit
to ezbuy/ezorm
that referenced
this issue
Feb 21, 2023
* ci: pin go version to support 1.19 and 1.20 * make: disable buildvcs See golang/go#26746
scbizu
added a commit
to ezbuy/ezorm
that referenced
this issue
Feb 21, 2023
* ci: pin go version to support 1.19 and 1.20 * make: disable buildvcs See golang/go#26746
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
cmd/goshells out to version control binaries to implementgo get.doc/install currently declares minimum supported OS versions for FreeBSD, macOS, and Windows, but only a minimum kernel version for Linux. Those requirements do not imply any particular version of the supported version control binaries, and those versions do matter in practice: in particular,
gitaccrued a large number of flags in between 2.7 and 2.18 (#26653).We should be explicit about which versions are supported for use with the
gocommand.(CC: @rsc @ianlancetaylor @bradfitz @myitcv @rogpeppe @trashhalo)
The text was updated successfully, but these errors were encountered: