search

leopard-js / sb-edit

Javascript library for manipulating Scratch project files
MIT License
51 stars 15 forks source link

1.0.0 release - move to semantic versioning? #156

Open towerofnix opened 1 month ago

towerofnix commented 1 month ago

sb-edit has plenty room to shake up in the future - #53, #93, #98, #100 - and maybe some of these are issues that we want to address before giving it a spiritual "1.0.0" release. But, on a practical level, it is now a package which certain other software depend on (i.e. leopard-website). Although package-lock.json has long addressed the worst concerns, still, to the end of smooth updates within package.json constraints, semantic versioning is a useful thing.

leopard was published as a semver project basically immediately. As far as we're aware there has only just recently even been a concern about bumping leopard to 2.x.y, see: https://github.com/leopard-js/leopard/pull/201#issuecomment-2207857285.

Changing toLeopard (we should perhaps change all such interfaces?) to be async - #154 - is a breaking change. One that's easy to prepare for - PullJosh/leopard-website#64 - but still breaking.

We don't personally see semantic versioning as making a statement about a certain "quality" or any other guarantee, for a project. It's just saying: this package has interfaces for usage in your code project, and they will continue to work, in the same shape, until the next major release.

We have somewhat arbitrarily used minor and patch 0.x.y versions and could discuss what we want to "count" for a minor/patch bump more specifically, but personally the main motivation is to treat breaking changes as major version bumps, so they can be more plainly documented e.g. in release notes or summaries of major API changes (maybe some of the issues linked at the top of this issue).

PullJosh commented 1 month ago

I'm on board with this as a practical choice. I think my gut instinct is to be precious about major releases, but there's no practical reason to treat them that way, as far as I can tell. Using major releases as a clear marker of breaking changes seems wise, and it makes sense to publish 1.0.0 so that we can then bump to 2.0.0 when we release a breaking change to the API.