Remove version from generated header

[marians]

This change removes the version number from the generated header.

Before this, many "Align files" PRs consist of meaningless changes like this one:

Checklist

• Update changelog in CHANGELOG.md.

[lyind]

Makes sense to me, I also noticed the clutter. But, might there have been a reason to add the version?

Anyways, LGTM

[ubergesundheit]

I want to voice my opinion without approving nor blocking this PR.

I agree the Align files PRs are annoying but I find the explicit version in the header helps me to identify if the auto-generated files are up to date or not. Without a version string I'll probably re-run devctl more often locally on my machine to verify if everything is using the latest versions.

A possible alternative would be versioned templates. So devctl can be updated independently from the actual version of the template. So the header would not include the devctl version but the version of the template.

[lyind]

A possible alternative would be versioned templates. So devctl can be updated independently from the actual version of the template. So the header would not include the devctl version but the version of the template.

This is a very good suggestion, IMHO.

[marians]

Would that be a Semver per template, or rather just an integer to increment with every change, or a last modified date?

[ubergesundheit]

Last modified date sounds good. A commit hash could be also useful for people wanting to see the who and why something in a template was changed.

[marians]

The problem with a commit hash is that it only exists after the change was made. So I'd favour a last modified date.

[ubergesundheit]

In my mind it could work like this: Like opsctl, devctl would load the templates from a repository during runtime. The information (hash + last modified date) would be available then

[marians]

In my mind it could work like this: Like opsctl, devctl would load the templates from a repository during runtime. The information (hash + last modified date) would be available then

IMO the chain of dependencies grows a bit long for what it's trying to accomplish.

• "Align files" PR in the repo is made by the Synchronize workflow in giantswarm/github
• Synchronize workflow used devctl
• devctl references specific template, based on what file it tries to generate.

Currently we already need three PRs (giantswarm/devctl, giantswarm/github and the target repo) to push a change through to the target repo.

[ubergesundheit]

Doesn't keeping templates in a separate repo and loading the repo inside devctl free us of doing the devctl and github PRs? assuming devctl is compatible.

[ubergesundheit]

Anyone working on this and is ready soon? Otherwise I want to try implementing this using //go:generate directives while keeping templates in the same repo

[marians]

@ubergesundheit Please go ahead! I was up for the minimal change this PR brings, but don't see me doing the other approach.