CI builds validate against last two versions of Go, dropping 1.14 and adding 1.16

[gliptak]

No description provided.

[Aneurysm9]

Can you update the list of tested versions in the README?

[gliptak]

@Aneurysm9 updated README

[codecov]

Codecov Report

Merging #1865 (acc7cdf) into main (cbcd4b1) will increase coverage by 0.2%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            main   #1865     +/-   ##
=======================================
+ Coverage   79.0%   79.2%   +0.2%     
=======================================
  Files        139     139             
  Lines       7477    7459     -18     
=======================================
+ Hits        5909    5910      +1     
+ Misses      1322    1303     -19     
  Partials     246     246             

Impacted Files	Coverage Δ
exporters/trace/jaeger/uploader.go	50.6% <0.0%> (-0.1%)	⬇️
sdk/export/metric/exportkind_string.go	0.0% <0.0%> (ø)
metric/number/kind_string.go	33.3% <0.0%> (+16.6%)	⬆️
attribute/type_string.go	33.3% <0.0%> (+23.3%)	⬆️
metric/instrumentkind_string.go	33.3% <0.0%> (+23.3%)	⬆️

[MrAlias]

I had initially added that this can skip the change log, but if we are going to change the minimum version of Go that we support we definitely need to include that in the changelog.

[MrAlias]

I'm a bit hesitant to make this change. By moving the minimum version number from 1.14 to 1.15 we are reducing the versions of Go we support and consequentially the number of users we can support here. If our goal is to promote as wide adoption of the project as we can achieve, this goes against that goal.

[gliptak]

#1064

[evantorrie]

I'm a bit hesitant to make this change. By moving the minimum version number from 1.14 to 1.15 we are reducing the versions of Go we support and consequentially the number of users we can support here. If our goal is to promote as wide adoption of the project as we can achieve, this goes against that goal.

Given that there may be issues related to changes in go-1.16 module handling, perhaps running tests across the current and two past versions of go is a reasonable solution.

[lizthegrey]

I'm a bit hesitant to make this change. By moving the minimum version number from 1.14 to 1.15 we are reducing the versions of Go we support and consequentially the number of users we can support here. If our goal is to promote as wide adoption of the project as we can achieve, this goes against that goal.

Supporting 2 versions of golang is in keeping with ecosystem standards, and it's worth noting that we aren't yet GA. once we're GA I could see the argument for supporting .15, .16, and .17 in parallel to accommodate slower movers. Remember golang comes out once per 6 months so that's 12 months of official support per major version (plus 6 months if we support N-2 and not just N-1 once hitting GA).

https://www.reddit.com/r/golang/comments/cmb5bp/is_there_an_lts_version_of_go/

[lizthegrey]

@Aneurysm9 this is going to need your approval to run the CI and then merge

[MrAlias]

From SIG meeting:

• When we release 1.0 we will want to pin our minimum supported version of Go.
• We are not there now, so let's upgrade and keep a floating support window of the current and last minor versions.