There are a few different things to consider when versioning your package. I'm generally trying to have the same version support 10, 11 and 12. I'll probably have a new major release for Umbraco 13. There could potentially be some issues with that approach. Say V1 of my package supports 10, 11 and 12, and V2 supports Umbraco 13. After I've released V2, Umbraco makes some breaking changes to Umbraco 12, should I release a new major as V3, which is for Umbraco 12 - although V2 is for Umbraco 13? It's probably a bit hypothetical as Umbraco ieally shouldn't be making breaking changes in minor releases. But it could also be that they introduce a new feature, which is more likely. Say a feature is added to both Umbraco 12 and 13 after 13 has been released. My V1 package is build against the Umbraco 10 dependencies, so that version can't use the new features in Umbraco 12. So far I haven't this hasn't been an issue for any of my packages yet, but it could happen in the future. 🤯

I haven't thought about this, but this really sounds like a (could be-) issue

Strictly speaking SemVer says you only increment a major when you make a breaking change to your public API. Using a new Umbraco feature, from a new Umbraco version, would only require you to increment by a minor if your API stays the same. However, if you've also got to change the version of .NET you're targeting along with Umbraco then you'll have to bump the major... and, yes, could end up "overtaking". To avoid this just increment your majors at the same rate as Umbraco, whether you're actually releasing or not. There's nothing that says you have to increment majors one at a time. You could have v1 for Umbraco 10-12 and v4 for Umbraco 13 and only actually use v2 and v3 if you need to create a version that targets v11 and v12 respectively. That's perfectly valid SemVer, and avoids having to match Umbraco's release cadence just to protect from overtaking.

Hmm thanks!