Add change type for developer tooling?

[NateEag]

I've been maintaining changelogs for a few projects at $DAYJOB using this format.

I've found them helpful not just for people using our software but for developers, too. It gives a quick high-level overview of the project's history and sometimes that's exactly what we need.

That dual use becomes a tension when I want to document changes I've made to our development tooling. Strictly speaking new and improved tooling is a feature, in some sense, but it clearly doesn't belong in the "Added" section as it will confuse most readers. Also, some tooling changes are bugfixes or removals, so they wouldn't go in the "Added" section anyway.

Would it make sense to add a change type for tooling?

Having one makes the history overview more useful for developers, while also making it easy to strip out the dev-only changes automatically for the non-developer version of the changelog.

I don't have a great name for this hypothetical section, since most of the current ones are past-tense verbs.

Right now I'd suggest either "Tooling" or "Toolsmithed". I'd happily take better suggestions.

[stuzer05]

I don't think that is a good idea to include tooling section to the general changelog format, as it only generally describes something being changed. It could be a document, development project or even something else. And tooling keyword kind of removes this "flexibility" of a changelog, making it "developers only" and not so obvious for other usages to other users. I think it must be a project-dependant question either to add a new section or not if it isn't necessary.

[NateEag]

I should have stated my assumption that projects using a "tooling" section should remove that section before publishing their changelogs and release notes, as it's only relevant for developers.

I do see your point, though.

The per-project decision about having different section types also makes sense to me.

Edit: I guess I did state that assumption. I should have checked my assumption about my assumptions. :D

[zanedp]

A change in tooling, such as upgrading to a new compiler, may be relevant beyond the developers. At my $DAYJOB, changing to a new compiler version requires a full regression test by the test organization.

[rdeago]

For library projects, a change of compiler / runtime library / framework version is likely to affect dependent projects, whose developers could be compelled to choose between upgrading their toolchain and losing the dependency. This is of course relevant to developers of other projects, that are users in the context of the library.

Even for end-user products, a change of compiler (or, for .NET projects, minimum .NET Framework version required) may introduce incompatibility with older OS versions.

That having been said, and keeping in mind that changelogs are for humans, as a user I'd rather read a "MyAwesomeApp now requires at least Windows 7 SP1" notice than "Changed TargetFramework to net461 in MyAwesomeApp.csproj". IMHO a changelog it's not about the changes per se, but the user-facing consequences of the changes.