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

Including Android fixes in 1.3.* releases #840

Open
elgatito opened this issue Oct 8, 2024 · 4 comments
Open

Including Android fixes in 1.3.* releases #840

elgatito opened this issue Oct 8, 2024 · 4 comments

Comments

@elgatito
Copy link

elgatito commented Oct 8, 2024

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
Copy link
Member

ahrtr commented Oct 8, 2024

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
Copy link

paskal commented Dec 21, 2024

@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
Copy link

paskal commented Dec 21, 2024

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
Copy link
Member

ahrtr commented Dec 21, 2024

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.

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

No branches or pull requests

3 participants