Including Android fixes in 1.3.* releases

[elgatito]

Hello,

One of the users reported issues with function not implemented on Android 14, and I have found this MR being merged year ago: #571

But I see that none of the 1.3.* releases include it.

But, why? That is not a breaking change, that is a fix, and Android 14 is not so rare, so I was surprised that it is not part of latest releases.

And since Alpha release requires Go 1.22, which, in turn, requires Windows 10 at minimum, so I am kind of locked to either move to Go 1.22 and block many Windows users, or keep on 1.21 and block Android users...

[ahrtr]

Usually we don't backport feature to stable release. But I won't insist on it for such safe and non-breaking change as you mentioned. So please feel free to raise a PR to backport it to release-1.3. Thanks.

[paskal]

@ahrtr @dusk125 updating go versions in the library are forcing all library users to update to the newer Go version and leads to unexpected side effects for the end users like forcing them to use the Go version which doesn't support their OS anymore.

go.etcd.io/bbolt v1.3.10 was on 1.21, v1.3.11 on 1.22, and the next one according to master would be on 1.23.

I would be extremely grateful if the features of the newer version are not used in the library, its version requirement to be downgraded to 1.21. It doesn't restrict end-users from using the newer versions but it allows users with valid cases for older go version to continue using it.

[paskal]

The general rule of thumb I personally use is to use something reasonably old for the libraries to keep backwards compatibility (so 1.18 for anything which requires generics, newer if newest features are required) and whatever newest version I find convenient for the binaries.

In this particular case 1.20 seems to be reasonable as it's last one supporting Windows older than 10: https://go.dev/doc/go1.20#windows

[ahrtr]

go.etcd.io/bbolt v1.3.10 was on 1.21, v1.3.11 on 1.22, and the next one according to master would be on 1.23.

Our policy on the go version is here. For stable releases (i.e. bbolt release-1.3 ), usually we stay on the latest patch release of a supported Go version, i.e. 1.22.10), but for a library like bbolt, we are good as long as the go version is 1.22. Once go 1.22 is out of support, then we will bump to 1.23.

I agree that it may cause some inconvenience to users if they insist on stay on an unsupported go version, i.e. 1.21 or even older versions. But the goal is to stay on a go version which is supported by golang team.