Post mortem mini on 12.5.0

I’ve seen no mention of this anywhere, but what happened to 12.5.0? We seem to have skipped directly to 12.5.1 with no indication about why.

–Noah

Because I created a git tag for 12.5.0 prematurely and we didn’t want to
update the tag :slight_smile: We don’t honestly see skipping patch version numbers as
a big problem, so we just incremented rather than go through the trouble of
modifying history.

–John

On Thu, Oct 8, 2015 at 4:30 PM Noah Kantrowitz noah@coderanger.net wrote:

I’ve seen no mention of this anywhere, but what happened to 12.5.0? We
seem to have skipped directly to 12.5.1 with no indication about why.

–Noah

I’m somewhat disturbed by this.

A git tag (to my understanding) is a reference of a point-in-time in the codebase, while the addition of a new released version with an identifier like 12.5.1 conveys that there must have been a 12.5.0 at some point, and something was wrong with it to patch and release a 12.5.1.

From the accepted RFC process, Chef releases attempt to adhere to Semantic Versioning, and the CONTRIBUTING docs support this and clarify which part of the version changes when.

So a statement like:

Seems a bit out of sync with the rest of the defined, agreed, accepted project methodologies, especially when a git tag isn’t changing history - it’s a repository reference point only.

Exactly the point, the 12.5.0 was tagged for release, the code in the tag was not the one planned, instead of releasing a broken 12.5.0, include the missing code, tag 12.5.1 and never build a broken 12.5.0.

TL;DR;: It makes sense to avoid releasing a mistake in my opinion.

I propose we:

  • remove the 12.5.0 tag, and not re-create it, since it was not released
  • update the blog post to reflect what specific version was actually released

I’ve had to steer a number of folks to 12.5.1 when they came to me reporting that their toolchain couldn’t seem to locate the 12.5.0 version after they read the blog post that specifically says 12.5 was released.

1 Like

I agree with the proposal and would add updating the 12.5 Release note to clear out this point.

Don’t get me wrong, I think the solutions proposed are good ones. I’m
questioning the release process decision making that brought us here in the
first place, so as to prevent this discussion next time.

I assume we have a different point on view on this, what is in a release should be what is on the tag, removing and redoing a tag involves some modifications to the git repo which may be undesirable as modifying the history of the repo itself.

I’m pretty sure your question is a good point and that this thread is a correct answer to it, defining what has to be done in this kind of cases.

My messages there are of course only my highly debatable point of view :slight_smile:

We use annotated tags for the chef project, which are commits. We do not use lightweight tags. You cannot delete or move an annotated tag without doing the equivalent of a force push to a public master branch and all that it entails with rewriting history.

That is both the reason why it was done and the reason why we can’t fix it, also the reason why this has happened in the past and will likely absolutely happen again in the future as well (although with better continuous delivery of the omnibus-chef artifact and removing humans from the loop that might not be correct, but certainly right now while humans are responsible for tagging versions they will make mistakes and this will occur).

I also don’t see anywhere in the SemVer spec where it addresses release artifacts or yanking versions or similar issues. It is solely concerned with versioning and we complied 100% with Semantic Versioning. Since we were releasing more than bugfixes we incremented MINOR and reset PATCH to zero. Then we needed to include an additional bugfix on top of that and incremented PATCH. Both of those steps are SemVer compliant. Then we did a release.

And if you can read anything in the SemVer spec suggesting otherwise, then what needs to happen is that we need to have an RFC cut to clarify that we follow SemVer, but not that, because we cannot follow that. Git sanity MUST trump SemVer if they are actually in conflict (but I doubt that they really are).

Now if there’s docs that suggest we released 12.5.0 then that’s broken and it simply got dropped. The 12.5.[0,1] released turned into a substantial yak shave involving people working late into the evening and there was a certain amount of collapsing at the finish line and whacking the release button. People are also currently very distract with the Summit, but if there’s any documentation that hasn’t been fixed after this weekend, that issue should definitely get raised again and get that fixed.