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

proposal: all: define deprecation policy for OS versions #19002

Open
mikioh opened this issue Feb 9, 2017 · 11 comments

Comments

@mikioh
Copy link
Contributor

commented Feb 9, 2017

As of 31 December 2016, 9-STABLE branch was discontinued; https://www.freebsd.org/security/security.html and Go 1.8 supports 8-STABLE through 9-STABLE; https://github.com/golang/go/wiki/FreeBSD. I think there's no reason to support releases that never come even with security fixes. Considering the transition period, I propose to drop the support for FreeBSD 9 or below at the next release of Go 1.9.

Thoughts?

@bradfitz bradfitz added this to the Proposal milestone Feb 9, 2017

@bradfitz bradfitz added the Proposal label Feb 9, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

commented Feb 9, 2017

SGTM to this non-FreeBSD user at least. I seem to recall hearing that FreeBSD users update pretty regularly. Is that true?

@minux, @mdempsky, @adg?

@adg

This comment has been minimized.

Copy link
Contributor

commented Feb 9, 2017

@minux

This comment has been minimized.

Copy link
Member

commented Feb 9, 2017

@reezer

This comment has been minimized.

Copy link

commented Feb 9, 2017

Something that might be worth mentioning is that the ports collection (so the "official" packages) rather quickly had various commits to remove compatibility code for FreeBSD 9. So third party software might break on a larger scale.

On the comment of quick updates I also want to mention that the first release of the FreeBSD 10 branch was in January 2014, which means that there have been three years of time to do a major upgrade.

Also currently FreeBSD 10 and FreeBSD 11 are supported and FreeBSD 12 is the development branch.

That is not meant to be an argument for or against this proposal, but just meant to give some context to non-FreeBSD users.

@mikioh mikioh added the OS-FreeBSD label Feb 9, 2017

@rsc rsc changed the title proposal: all: drop support for FreeBSD 9 or below proposal: all: define deprecation policy for OS versions (incl FreeBSD 9) Feb 13, 2017

@rsc

This comment has been minimized.

Copy link
Contributor

commented Feb 13, 2017

We don't have a clear policy about when to drop support for specific systems. It would be nice if we could establish a general rule.

Maybe the policy should be: after an operating system version is no longer supported by the vendor, Go may drop support after the next two releases, and the release notes for the final release with support must mention that support is going away in the next release.

For example, FreeBSD 9 was dropped on Dec 31 2016; the next two Go releases after that are Go 1.8 and Go 1.9, and we'll likely drop in Go 1.10, but if so we must announce that in Go 1.9's release notes.

-rsc for @golang/proposal-review

@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2017

Looks like this issue is hijacked. I'll open another issue for code cleanup.

@mikioh mikioh removed the OS-FreeBSD label Feb 14, 2017

@mikioh mikioh changed the title proposal: all: define deprecation policy for OS versions (incl FreeBSD 9) proposal: all: define deprecation policy for OS versions Feb 14, 2017

@4ad

This comment has been minimized.

Copy link
Member

commented Feb 14, 2017

As a data point, gcc obsoleted the support for Solaris 9 in GCC 4.9 (April
2014), and removed its support in GCC 5.0 (April 2015) when the extended
vendor support for Solaris 9 ended in 2014.
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00728.html

Minor nitpick, Solaris 8 and Solaris 9 are still supported, they
are in what Oracle calls "Sustaining Support phase" for an indefinite
period.

However, we never supported Solaris 8, 9, or 10, so we don't have
to worry about any of that.

However, IIRC correctly Windows XP is still supported in the embedded
SKU, or if you have a special service contract. I think from the
perspective of the Go project, we should continue to treat Windows
XP as a supported system.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2017

Following my recent comment on #19075, it sounds like we're happy with the "Go 1.N can announce that support for will be dropped in Go 1.(N+1)".

Criteria for the cost-benefit analysis for operating systems parallel the ones for hardware in that issue:

  • Availability of and support for the OS. If the OS version is no longer available and/or no longer supported, that reduces the expected benefit.
  • Actual or expected user base. If no one is using that version, that reduces the expected benefit.
  • Incurred ongoing costs of keeping old support (builders, compiler/runtime/syscall code paths, and so on).

Again it may be that the best we can do ahead of time is list the costs and benefits to consider, but not how they must be weighed.

Is that enough? Other considerations?

@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2017

Accepted pending wiki page, like #19075.

@binarycrusader

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2017

For what it's worth, I agree with @4ad 's comments on Solaris. Realistically, Go generally only needs to support the latest update release of Solaris (e.g. 11.3).

@stevenh

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2017

With respect to FreeBSD following the official supported versions is an option, which can be seen here:
https://www.freebsd.org/security/security.html#sup

So currently only 10 and 11 are supported, all other version have reached their EOL.

Not sure if that would work for other OS flavours?

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