RFC: Drop support for golang 1.2.x and 1.3.x

[flavorjones]

Proposal to drop support for golang 1.2.x and 1.3.x

This issue describes a proposal to drop support for golang 1.2 and 1.3 from the Cloud Foundry go-buildpack. The community is asked to comment on this proposal.

The Challenge

Under our current, informal, "skinny buildpack" policy, we do not deliver binaries that are no longer supported upstream, for some definition of "supported". Generally, "supported" means "will receive security updates."

According to this thread on the golang developer mailing list, only the current major branch will receive security updates.

http://grokbase.com/t/gg/golang-nuts/159ar9tbed/go-nuts-end-of-life-support-for-go-1-3

This appears to be a "soft" policy, as 1.4.x received an update to 1.4.3 in September of this year to address a set of CVE vulnerabilities.

That said, it appears clear that 1.2 and 1.3 are no longer receiving security updates, and so could reasonably be declared "unsupported" by upstream.

The Proposal

We propose here simply to drop golang 1.2 and 1.3 support from the buildpack. Currently (v1.6.2 as of this writing on 2015-10-12), the buildpack vendors 1.2.1, 1.2.2, 1.3.2, and 1.3.3.

I'd like to implement this change no later than go-buildpack v1.6.4, or the end of October 2015.

How you can help

Please comment on this issue! If you're relying on golang 1.2 or 1.3 in production, we'd like to know how this is going to impact you. If you foresee challenges regarding upgrades to golang 1.4 or 1.5, we'd like to know.

Thank you!

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/105512206.

[gertd]

+1 for removing old versions.

In general, would it be an idea to only include the latest binary payload of the compiler binaries and make the other, well-defined set, download on demand? This could significantly reduce the total binary payload of the go build pack in cf-release which today is .5 GB (438,021,879).

Only the PHP build pack is larger then the go build pack.

[drnic]

The hiccup in Go is the Godeps/Godeps.json files that have very specific
versions in them. Cutting back on Go versions constantly means that
community Go apps have a short lifespan before they no longer "just run".
But perhaps there is a way to fix this in godep?

On Wed, Oct 14, 2015 at 10:17 AM, Gert Drapers notifications@github.com
wrote:

+1 for removing old versions.

In general, would it be an idea to only include the latest binary payload
of the compiler binaries and make the other, well-defined set, download on
demand? This could significantly reduce the total binary payload of the go
build pack in cf-release which today is .5 GB (438,021,879).

Only the PHP build pack is larger then the go build pack.

—
Reply to this email directly or view it on GitHub
#22 (comment)
.

Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic

[tcnksm]

+1 for removing old versions.

We can edit Godep.json's "GoVersion" by hand to use available version.

[jtarchie]

See related: tools/godep#297 and heroku#100

[flavorjones]

It looks like @kr is open to a PR to godep that would simply save major.minor in the GoVersion field, which is exactly the behavior we want.

I'll prioritize a story for that.

[nathany]

It appears this issue was addressed in 61721ad (v1.7.0)

[flavorjones]

Yes, thanks. This was released in v1.7.0. Apologies for not closing this out.