Conversation
|
|
||
| ### Go Directive Policy | ||
|
|
||
| The `go.mod` file's `go` directive will always be set to `N-1`, where `N` is the latest stable Go version. This means: |
There was a problem hiding this comment.
When exactly does the bump happen after a Go release? Day one? After a month for ecosystem stabilization?
There was a problem hiding this comment.
@ferhatelmas I was pondering on this, I'm not sure it is worth setting in stone a cooldown period for bumping the project. The reason being, when a new release takes place N-2 is then EOL. Keeping main up to date should benefit users that keep abreast with the changes and help the community understand any impact sooner rather than later.
That being said, the version constraints for renovatebot are manually set at the moment. This will need to be changed to align with whatever approach we go for.
For the ecosystem stabilization aspect, perhaps we could have a waiting period before cutting a new go-git release. What do you think?
There was a problem hiding this comment.
Due to semantic versioning, bumping min go is a breaking change so it will be a new version, right? i.e. v7 for go1.26
If so, IMHO, it is better to release as soon as possible when a new go version is out.
There was a problem hiding this comment.
Due to semantic versioning, bumping min go is a breaking change so it will be a new version, right?
Historically this project never tied minimum Go versions with go-git versioning. For illustration purposes, within go-git's v5 we bumped the minimum Go version from 1.13 to 1.23. There are no further guarantees apart from the latest go-git version supporting only the last 3 stable Go release lines - which this RFC aims to reduce to 2.
Go provides a minimum of 2 years guarantee (4 Go releases) for backwards compatibility via GODEBUG, users should be able to opt-in/out of new behaviours within that timeframe - limiting the impact of breaking changes. Kubernetes uses this as a way to provide Go minor bumps in Kubernetes patch releases. As go-git is a library, users should be able to lean on Default GODEBUG Values to the same effect.
That being said, I completely understand why that would make sense and the benefits it could bring. My take is that although it sounds fairly connected to this RFC, I believe it is still an orthogonal subject and could have side effects which should be considered in isolation, as its own RFC.
pjbgf
force-pushed
the
goversions
branch
2 times, most recently
from
6d49ef6 to
990b425
Compare
There was a problem hiding this comment.
Pull request overview
This RFC proposes formalizing go-git's Go version support policy to officially support only the last 2 stable Go release lines (N and N-1), reducing from the current 3-version policy. The change aims to align with Go's upstream support policy, improve security posture for runtime CVEs, and reduce maintenance burden while maintaining a reasonable upgrade path through semantic versioning.
Key changes:
- Establishes N-1 policy for
go.moddirective (e.g., when Go 1.26 releases, go-git requires Go 1.25) - Reduces CI testing matrix from 3 to 2 Go versions (minimum and latest)
- Applies only to v6; v5.x branch continues with 3-version support on best-effort basis
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
I'm not really familiar with go-git's codebase, I would wonder whether something like "as old as the version of Go packaged in debian stable" makes sense though Generally I think this makes sense! |
Signed-off-by: Paulo Gomes <[email protected]>
|
Merging under lazy consensus after the RFC being open for over 60 days with no blocking concerns. |
x-ref: go-git/go-git#1769 Signed-off-by: Paulo Gomes <[email protected]>
x-ref: go-git/go-git#1769 Signed-off-by: Paulo Gomes <[email protected]>
x-ref: go-git/go-git#1769 Signed-off-by: Paulo Gomes <[email protected]>
x-ref: go-git/go-git#1769 Signed-off-by: Paulo Gomes <[email protected]>
This RFC opens up the discussion around the support Go versions policy, proposing to officially support only the last 2 stable Go release lines, reducing from the current policy of supporting the last 3 stable release lines.