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

proposal: doc/install: define minimum supported VCS versions #26746

Open
bcmills opened this Issue Aug 1, 2018 · 17 comments

Comments

Projects
None yet
9 participants
@bcmills
Member

bcmills commented Aug 1, 2018

cmd/go shells out to version control binaries to implement go 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, git accrued 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 go command.

(CC: @rsc @ianlancetaylor @bradfitz @myitcv @rogpeppe @trashhalo)

@bcmills bcmills added this to the Go1.12 milestone Aug 1, 2018

@bcmills

This comment has been minimized.

Member

bcmills commented Aug 2, 2018

Marking NeedsDecision to determine:

  • whether we want to specify versions, and
  • if so, what criteria to use to determine them.
@mostynb

This comment has been minimized.

Contributor

mostynb commented Aug 4, 2018

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?

@bradfitz

This comment has been minimized.

Member

bradfitz commented Aug 9, 2018

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

@rsc

This comment has been minimized.

Contributor

rsc commented Aug 10, 2018

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.

@bcmills

This comment has been minimized.

Member

bcmills commented Aug 10, 2018

essentially every git that's on a supported OS by default needs to work.

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:

  • Debian 8 “Jessie” is in its LTS phase. It shipped with Git 2.1.4, but has a backport of 2.11.0 available. Does that mean we need to support 2.1.4, or just 2.11.0?
    • Debian “Jessie” shipped with Go 1.3.
  • Ubuntu still supports Ubuntu 14.04 LTS, which shipped with Git 1.9.1. Does that mean we need to support Git 1.9.1?
    • From what I can tell, Ubuntu 14.04 LTS is ~9 Ubuntu releases ago. It shipped with Go 1.2, with a backport to Go 1.3.
  • Slackware 14.0 has not been EOL'd yet, and it shipped with kernel 3.2.29 and Git 1.7.12. Does that mean that we need to support Git 1.7.12?
@bcmills

This comment has been minimized.

Member

bcmills commented Aug 10, 2018

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.)

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Aug 10, 2018

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?

@bradfitz

This comment has been minimized.

Member

bradfitz commented Aug 10, 2018

I suppose we could always vendor something like https://github.com/src-d/go-git . Not that I'm seriously suggesting that.

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.

@mostynb

This comment has been minimized.

Contributor

mostynb commented Aug 10, 2018

GitHub suggests using 1.7.10 in their help[*]:
"There's no minimum Git version necessary to interact with GitHub, but we've found version 1.7.10 to be a comfortable stable version that's available on many platforms."

[*] 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.

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.

Sounds like an interesting side project, but would require some thought to avoid privacy/GDPR/etc issues.

@rsc

This comment has been minimized.

Contributor

rsc commented Aug 13, 2018

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:

  • latest Ubuntu
  • latest Debian stable
  • latest RedHat Fedora
  • oldest Ubuntu LTS still supported by Ubuntu

Anything else?

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Aug 14, 2018

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.)

@bradfitz

This comment has been minimized.

Member

bradfitz commented Aug 14, 2018

@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.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Aug 14, 2018

@bradfitz Yeah, I forgot about that question. I don't know.

@myitcv

This comment has been minimized.

Member

myitcv commented Aug 14, 2018

Maybe we should define which Linux distros we support and then it's implied which git versions we need to support.

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).

oldest Ubuntu LTS still supported by Ubuntu

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.

@thepudds

This comment has been minimized.

thepudds commented Aug 23, 2018

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 rsc modified the milestones: Go1.12, Go1.13 Nov 14, 2018

@rsc rsc changed the title from doc/install: define minimum supported VCS versions to proposal: doc/install: define minimum supported VCS versions Nov 14, 2018

@gopherbot gopherbot added the Proposal label Nov 14, 2018

@rsc rsc removed the NeedsDecision label Nov 14, 2018

@andybons

This comment has been minimized.

Member

andybons commented Dec 5, 2018

@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?

@bcmills

This comment has been minimized.

Member

bcmills commented Dec 6, 2018

can you describe what sorts of things break when using an older version of a VCS tool?

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 git archive) and it turns out that the flag isn't present in some older version still in use. Then that whole command fails, or (less frequently) git ignores the flag and our fix is ineffective on that version.

Also would the go tool enforce or otherwise check the version and give a helpful error message?

If we know some version that we definitely don't support, we could emit a helpful error.
If we know what version we do support, then perhaps we could emit a helpful message only if the command fails (analogous to the behavior for #28221).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment