Track releases with tags about anthos-service-mesh-packages HOT 8 CLOSED

Good point. I was imagining that we'd wait for an ASM release before we made any breaking script API changes, but I'll make sure and work that into the detailed design.

from anthos-service-mesh-packages.

You said this, but just to make sure I capture the intent properly I'm going to rephrase with more words.

Migrations are out of scope since we really have no way to verify that any two starting states would be the same. Fully reproducible is also out of scope since we want to keep the ability to e.g. push CVE bugfixes even to minor/point branches. However, given a particular ASM release and a particular release of this repo, two installations with the same CLI flags should result in the exact same installation.

This wouldn't 100% cover rollbacks, but should cover upgrades/downgrades enough.

Does all of that "mesh" (ha!) with your idea?

from anthos-service-mesh-packages.

We should not be pushing even CVE fixes to patch releases. For instance, if we discovered a CVE right now in 1.6, we would not update 1.6.8, but would produce a new patch (1.6.9 or whatever). The tags should be static.

from anthos-service-mesh-packages.

If we do that, then we can't have the tag follow ASM releases. There will be times where we need to push a bug fix to the config repo even though there's no change in ASM, and the tag that customers will be different from the version of ASM that they're using.

I agree that things should be reproducible, but I'm not sure that needing to come up with our own versioning system is the right answer.

We could have a "config" number and add it to the version, so 1.6.8-asm.4-2 would be the 2nd version of the config for ASM 1.6.8 revision 4. Then customers who really wanted reproducibility could have the option to pin to a specific config version, and others could just point at 1.6.8-asm.4 which would become static whenever ASM had another release.

Or I guess we could always test and release ASM and config together, if I could convince them that bumping a version just because we made a typo in a yaml file was acceptable.

Is there a specific model for this you had in mind?

from anthos-service-mesh-packages.

I think reproducibility is critical for our users to have confidence in their ability to upgrade. We can accomplish this with static tags, meaning that bug fixes in config have to wait for ASM releases to ship, or that we have a major.minor.patch.subpatch.subsubpatch version number. Or, we could accomplish this in the CI environment by translating the tag to a commit hash, and somehow storing a record of that commit hash at install time.

Generally speaking, having a release tag mutate in a repo is an anti-pattern, so I would recommend using some form of static tags.

from anthos-service-mesh-packages.

Two things:

1. I apologize, I was getting refs and tags mixed up somehow. Yes, mutable tags are bad.
2. I just learned that semver allows metadata by using a +

So: ASM versions get a branch, config versions get a tag which is "${ASM_VERSION}+config${N}" where is a monotonically increasing number which resets whenever the ASM version changes. This is stable per-commit, is obviously associated with an ASM release, and it's also easy to recognize which is the latest tag for an ASM release by just sorting.

If that sounds reasonable then we can call it a design and make some tools.

from anthos-service-mesh-packages.

That sounds like an excellent solution. I think some semver implementations may treat tags with metadata as preview releases, but I don't think that should impact this, since we are manually cloning with git.

from anthos-service-mesh-packages.

"${ASM_VERSION}+config${N}" SGTM, a question would be is N enough to capture breaking changes to the interface of the script?

from anthos-service-mesh-packages.