Versioning, history and breaking changes

[teunmooij]

What's the strategy for versioning of the payload software? (so I'm talking about the software version, not document versioning)

I've noticed a couple of things:

• Patches sometimes include substantial improvements (eg 1.6.24. introduces bulk updates and deletes)
• Patches sometimes have breaking changes (bulk update is overload of existing function, but original parameters now give different return type)

During the last couple of weeks I've already had to fix a broken solution twice because of breaking changes in minor updates. I'd really like to keep my service up to date, so ideally I'd only have to worry about broken changes when there's a major version change.

Also I'm building some plugins and would like to keep them up to date. Where can I find a version history, so I can do a gap analysis? Or do I need to go through all the commits for this?

[DanRibbens]

Hey @teunmooij, great questions and feedback!

First off—

Patches sometimes have breaking changes (bulk update is overload of existing function, but original parameters now give different return type)

This was simply a bug in that release which went unnoticed until now. We intended to have zero breaking changes which is why that was released as a patch. I'll get an update out on this shortly.

Going forward we are using semver for all releases. We've heard similar feedback on about this already after some of our bigger releases that did include breaking changes and arguably could have been major instead of minor.

We document all the breaking changes in the CHANGELOG.md which should be the only place you need to check.

Hopefully this helps you, we take breaking changes very seriously and do everything we can to avoid them.

Good luck on your plugins and et me know if there is anything else we can do!

[teunmooij]

Thanks for answering. Happy to here that you'll be applying semver.
I completely missed that changelog file. That's exactly what I was looking for.