More-usefully versioned scaffoldings

[stevendanna]

It would be useful if scaffoldings were versioned according to the version of the underlying language package. That is, if core/go/1.11.2 exists, then core/scaffolding-go/1.11.2 exists and uses core/go/11.11.2.

Currently, scaffoldings such as scaffolding-go have no meaningful pkg_version. Other scaffoldings have versions that do not appears to be related to the version of the underlying language package. This can become problematic for users of these scaffoldings trying to manage medium to large code bases.

If the versions of the scaffolding were based of the underlying version of the language, then downstream users could more easily control the version of the language they were compiling with.

OMG, don't you know pinning is the horrible old way?

Yes, but upgrading to a new version of a language is not an atomic event (even for "minor" version bumps). Further, this presupposes a particular shape of the downstream build system.

In our Go code base for instance, we do attempt to keep up to date. However, a minor version bump might mean addressing many minor formatting changes that have been introduced in gofmt (a mechanical task but one we still want to go through code review) and resolving bugs that the new version introduced. While this work is underway, it is nice to be able to pin to the known good version of the language so other people can make progress.

Yeah, but you can pin to the fully-qualified ident!

Yup! We can! But, I don't live in the glorious future where every part of our build/dev setup lives in Habitat. For instance, I may want to centrally manage the version of Go that we use so that CI scripts, development scripts, and other tooling can all be sure to get the same version. For example, in my repository, I would like to have a GOLANG_VERSION file. This file would drive the management of many different components that require Go. To keep us on latest, we have automation that is able to automatically open PRs for such a file when a new core/go version is available.

While we could use that same tooling to manage a pin of core/scaffolding-go, it just becomes a bit burdensome as we have to get the list of available scaffoldings and check their DEPS for the version of Go we are pulling in. While it isn't complicated code, it is just more API requests that could fail and more code people have to understand when updating the build system.

If instead we knew that core/go version updates would come with a core/scaffolding-go update, then we could make our dependencies "core/scaffolding-go/$(cat ../GOLANG_VERSION)" and call it a day.

What do y'all think?

[predominant]

Should this be discussed and formed into an RFC for Scaffolding?

[chefsalim]

Discuss in the context of scaffolding being deprecated.