Bump versions

[joswarmer]

@ftomassetti
After a lot of nuisances with e.g. github tags being incorrect docker tags etc. I now have a script that does the following interactively using changesets:

• Ask which packages to include (answer by SPACE-RETURN for all packages)
• Ask which packages get a major version bump
  • SPACE-RETURN will result in a major version bump
  • RETURN will ask a new question which packages get a minor version bump
    • SPACE-RETURN will get a minor version bump
    • RETURN will get a new patch version
• A short description.
  • Don’t leave this empty, it requires some text. The text ends up in a CHANGELOG.md file (per package) cumulatively for each version. I have not yet checked in this file, but we can do that
• Question whether this all is ok:
  • ENTER (is yes)

The script then automatically:

• updates the versions of all packages, and also the versions of the internal dependencies between the packages (both in the package.json).
• Creates a tag @lionweb/repository@
  • (Actually changesets creates tags for each package, but I delete all but the top one)
• Commits all changes to the package.json files and the new tag to git
• Pushes this commit

On the CI this results in the tag being added to the repository and a docker image to be published on github.

Note that the update of the version numbers is done at release time, just before releasing.

[ftomassetti]

Hi Jos, This looks very convenient!

Regarding what you wrote in the description, these two parts seem in contradiction:

Ask which packages to include (answer by SPACE-RETURN for all packages) Ask which packages get a major version bump

and this:

updates the versions of all packages, and also the versions of the internal dependencies between the packages (both in the package.json).

Why ask about which packages to include if later all the packages are updated? Or do you mean all the packages that need to be updated, as they were selected at the previous step?

I think that it would be simpler to always update the version of all packages, even if just one of them changed. Otherwise, the different packages could progress independently and we could end up having different versions for each package. As a user, I would then need to figure out which versions of which packages work together

[joswarmer]

All packages will be bumped together as described in the config.json.

[joswarmer]

It seems a great addition to the project! I just added comments about convenience, but my understanding of changeset is limited and I tend to think in the terms of the equivalent gradle plugin, so I may be wrong on some comments

changesets can do much more, like e.g. publishing and automatically creating release notes. The nice thing about it is that you can do most steps separately, and I used only a small part of what is available.