Inconsistent handling of YEAR substitution across generators

[felix-kaestner]

Background

#544 added a year option to generator commands (object, crd, rbac, and webhook), allowing callers to substitute a YEAR placeholder in boilerplate header files with a specific value.

Problem

The applyconfiguration generator is missing the year option and unconditionally replaces YEAR using time.Now().UTC().Year(), leading to inconsistent behaviour.

The full call chain is:

1. controller-tools/pkg/applyconfiguration/gen.go#L215
2. controller-tools/pkg/applyconfiguration/gen.go#L293
3. code-generator/cmd/applyconfiguration-gen/generators/targets.go#L60
4. gengo/v2/execute.go#L59

Proposed Solution

Add a optional year option to the applyconfiguration generator, which when set, will take precedence. This change would be backwards compatible, as if the option is not specified, the current logic stays as it currently is.

Additionally, the other generators could have same logic, of defaulting to the current year as a subsitution for the string "YEAR" if not overridden by the option.

[sbueringer]

I saw multiple comments from @liggitt on k/k PRs that the year is not required anymore in the copyright header.
(I don't have any additional context on this)

I wonder if accordingly we should recommend to stop generating files with the year.

[liggitt]

I saw multiple comments from @liggitt on k/k PRs that the year is not required anymore in the copyright header.
(I don't have any additional context on this)

xref kubernetes/steering#299

I wonder if accordingly we should recommend to stop generating files with the year.

In kubernetes/kubernetes, we stopped including years in generated files many years ago (kubernetes/kubernetes#59172) because they produced huge diffs on every year boundary and broke CI

[camilamacedo86]

End users often prefer having the year included in the header. While it’s no longer required for the k8s repo, many projects still care about it.

We’ve recently seen similar requests in Kubebuilder as well—for example: kubernetes-sigs/kubebuilder#5553

Given that, I think consistency is key, and I don’t see any downside to including it.

[alvaroaleman]

There is always a cost to adding code and I don't really think it was a great idea to ever add this option elsewhere, given the same netresult can already be achieved by simply passing in a header file that has the correct year in it already.

[camilamacedo86]

There is always a cost to adding code and I don't really think it was a great idea to ever add this option elsewhere, given the same netresult can already be achieved by simply passing in a header file that has the correct year in it already.

More importantly, this creates inconsistency with controller-gen, which causes problems for users.

.PHONY: generate
generate: controller-gen
	"$(CONTROLLER_GEN)" object:headerFile="hack/boilerplate.go.txt",year=$(YEAR) \
	applyconfiguration:headerFile="hack/boilerplate.go.txt" paths="./..."

With this setup, some outputs, such as CRDs, behave differently from others, such as SSA. The result is inconsistent generated files. Be aware that a project can have both scenarios, CRDs with or not SSA annotations.

Then, this should be consistent across all generators. Otherwise, it is confusing for users and is a bug.

So, I do see only 2 options here:

1. a) Fix and ensure consistency
2. b) No longer support pass the YEAR in any. (but that would be breaking change and besides k8s no longer care about the YEAR anymore, many end users and projects care so I would not go in this direction)

[camilamacedo86]

/assign

The PR #1379 fix this one