fix: add examples to major, minor and patch changes

[arielleleon]

No description provided.

[seanmcculloch]

Minor version changes could be specifically strictly addition-only changes in the results (including dependency/capsule changes). For example adding a new QC metric to the quality_control.json along with an image, where everything else is left unchanged

[tmchartrand]

add "any code update that changes output file content, even if that is fixing previously incorrect behavior"

[tmchartrand]

I'd say "do not alter output contents". Content vs structure is a big question here - I'd say writing to NWB 2.1 instead of 2.0 (changing structure in a non-breaking way) might make the most sense as a minor version (essentially bumping a dependency as in Sean's comment. but any change of content should be a major version (under strict semantic versioning anyway.
In my view this is perhaps a reason not to use strict semantic versioning, though I'm a bit undecided here.

[tmchartrand]

also clearly an actual patch: bug fix that simply enables a job that was previously failing to generate results (since this isn't changing contents)

[tmchartrand]

As I said in one of the comments, I kind of think that strict semantic versioning might not satisfy our needs here (see for instance numpy/numpy#10156). And even if it does, we definitely need it to be determined by more detail than is captured in conventional commits.
Here's a stab at some categories from angular commits and what I feel might make sense for assigning major/minor/patch to each. I think the biggest thing that's missing from conventional commits is that fix/refactor/feat changes can each be breaking or non-breaking, and that there is a difference between breaking by changing content (downstream process may be wrong) and breaking by changing structure or something more fundamental (downstream process fails entirely).

build: Changes to build system or external dependencies (larger than a dependency bugfix patch) - minor
feat: A new feature (added to output without changing existing) - minor
refactor: A code change that neither fixes a bug nor adds a feature - minor
fix: A bug fix (fix failures only) - patch

feat/refactor[breaking]: if one of the above fundamentally changes the processing approach or output structure to the extent that results before vs after are not directly comparable - major
fix[breaking]: A bug fix resolving (changing) erroneous output - minor (but also proactively reprocess and highlight in changelog)

perf: A code change that improves performance with output unchanged - minor
ci: Changes to CI configuration files and scripts - patch
docs: Documentation only changes - patch
style: Changes that do not affect the meaning of the code (white-space, formatting, etc) - patch
test: Adding missing tests or correcting existing tests - patch

[dyf]

I like Tom's suggestions. If there's no disagreement, let's add them in the policy under separate categories for major/minor/version

[arielleleon]

@tmchartrand - thanks for the feedback. Can you take a look at the latest updates?

[tmchartrand]

This looks good, except I realized I was thinking of "patch" as the least-change option, but some of those categories should actually just lead to no update - I'll clarify soon!