Time to cut a new release?

[tomasaschan]

In one of our projects, we have a dependency on sigs.k8s.io/kubebuilder-declarative-pattern v0.15.0-beta.1.0.20240926141202-cf8082c623b8 where the hash at the end points to the latest commit on master. Everything seems to work.

But if we do go get -u ./... && go mod tidy in this project, it selects v0.15.0-beta.2 which then seems to run into a bunch of compatibility issues with other k8s libraries:

λ go vet ./...                                                
# sigs.k8s.io/kubebuilder-declarative-pattern/commonclient
../../../pkg/mod/sigs.k8s.io/[email protected]/commonclient/factory_cr15.go:14:28: not enough arguments in call to source.Kind
        have ("sigs.k8s.io/controller-runtime/pkg/cache".Cache, client.Object)
        want ("sigs.k8s.io/controller-runtime/pkg/cache".Cache, object, handler.TypedEventHandler[object, reconcile.Request], ...predicate.TypedPredicate[object])
../../../pkg/mod/sigs.k8s.io/[email protected]/commonclient/restmapper_cr15.go:15:17: undefined: apiutil.NewDiscoveryRESTMapper
# sigs.k8s.io/kubebuilder-declarative-pattern/pkg/patterns/declarative/pkg/applier
../../../pkg/mod/sigs.k8s.io/[email protected]/pkg/patterns/declarative/pkg/applier/direct.go:104:59: f.OpenAPIGetter undefined (type "k8s.io/kubectl/pkg/cmd/util".Factory has no field or method OpenAPIGetter)
../../../pkg/mod/sigs.k8s.io/[email protected]/pkg/patterns/declarative/pkg/applier/direct.go:106:77: too many arguments in call to d.inner.NewFactory(opt).Validator
        have (string, *"k8s.io/cli-runtime/pkg/resource".QueryParamVerifier)
        want (string)
../../../pkg/mod/sigs.k8s.io/[email protected]/pkg/patterns/declarative/pkg/applier/direct.go:138:24: cannot use sets.NewString() (value of type "k8s.io/apimachinery/pkg/util/sets".String) as "k8s.io/apimachinery/pkg/util/sets".Set["k8s.io/apimachinery/pkg/types".UID] value in struct literal
../../../pkg/mod/sigs.k8s.io/[email protected]/pkg/patterns/declarative/pkg/applier/direct.go:139:24: cannot use sets.NewString() (value of type "k8s.io/apimachinery/pkg/util/sets".String) as "k8s.io/apimachinery/pkg/util/sets".Set[string] value in struct literal

Is it time to cut a new release to avoid these issues? What is the process for that?

cc @justinsb

[tomasaschan]

I found this document but it refers to the kuberentes-template project so I'm not sure how outdated it is...

[justinsb]

Yes, let's cut a new release. I pulled these two TODOs out of PR #408

TODO: Should we rename master to main now?

TODO: Do we want to do a bulk catch up, where we create releases aligned with each version we missed?

I think we should rename master to main.

We can also do a bulk catch-up if that is useful, bumping controller-runtime versions one major at a time and creating release branches for them. I think we should do that at the same time if we think it's useful. But ... is it useful?

[tomasaschan]

But ... is it useful?

Doubt it. And if someone comes and asks for it, we can always do it later - just cut a new branch, downgrade to the earliest version we haven't published a corresponding release for, and create tags there for each version we need to support (or just all of them while we're st it).

[guillaume86]

Sorry if it's not the best place to ask but I'm a bit lost as a newcomer to the whole ecosystem: is declarative-pattern usable with kubebuilder v4?
And if so, is there an updated tutorial somewhere?

[tomasaschan]

Thanks for the reminder on this!

@justinsb I was going to start cutting branches and tags etc according to the branching docs but it turns out I'm lacking some access to do some of the stuff. We also have this which I don't know if it's enforced by any automation or just a left-over from some template used in the the project inception...

[justinsb]

I'm trying to get you the permissions in kubernetes/org#5563 . I can also apply tags on your behalf if you'd like. Ideally we'd get some automatic tagging - we do have that e.g. in kOps and it works quite well in that we can tag things with PRs, but uploading releases to github still requires permissions so we still want to make you a project admin/maintainer.

[justinsb]

Having written that, I realized that we should probably just use the tooling for the tags ... #419

I still want to get you elevated permissions @tomasaschan , but the tooling works quite well for us in kOps.

[tomasaschan]

I don't have any strong opinions on exactly how we do things, so whatever works :) As long as it's well (enough) documented so I can figure out how to do stuff without dedicating too much time for tooling, and if it's used by other adjacent projects I'll assume that's the case.