search

LionWeb-io / lionweb-typescript

Implements (select parts of) the LionWeb specification, and tooling around that - all in TypeScript.
Apache License 2.0
10 stars 4 forks source link

Consider using changeset to organize releases #149

Open ftomassetti opened 2 months ago

ftomassetti commented 2 months ago

For debugging, it could be a nice to have to be able to connect each version released on NPM with a specific tag in the repository. Perhaps using changeset, as the lionweb-repository started doing could help.

dslmeinte commented 2 months ago

I thought I did that (manually), but it turns out I didn't. I'll add tags after-the-fact now. Using changeset is certainly a good idea – I'll consider that the second part of this issue, maybe to-be-done after we've gained some experience on lionweb-repository.

dslmeinte commented 2 months ago

Also, @ftomassetti : I think it's inevitable to have one tag per package (core, utilities, validation, cli) per version – agree?

joswarmer commented 2 months ago

As we publish packages separately, we need a tag per package indeed. This is different from the lionweb-repository.

ftomassetti commented 2 months ago

Also, @ftomassetti : I think it's inevitable to have one tag per package (core, utilities, validation, cli) per version – agree?

I thought the packages were released all together, but at a closer look most of them seem to have the same version (0.6.3-beta.0) with the exception of the cli module (0.6.4-beta.0). So I understand they can be released independently and their version numbers can vary independently.

My main doub is: how do I know that I should use the cli module 0.6.4-beta.0 with the core module 0.6.3-beta.0, the utilities module 0.6.3-beta.0, and the validation module 0.6.3-beta.0? Will this be written in some documentation or perhaps should I look at the packages.json to figure it out?

What if I want to do changes in the utilities module next? Will that become version 0.6.4 (as the utilities previous version was 0.6.3) or 0.6.5 (as the highest previous version across all packages was 0.6.4)?

I understand that if the packages evolve separately managing tags get a bit more complicated. So if I understand correctly, you would add, let's say, a tag named utilities-0.6.3 and that means that the content of package utilities will contain the code used to the release 0.6.3. All the other packages contained what happened to be their state at that time but that is irrelevant. Am I understanding correctly?

dslmeinte commented 2 months ago

Yes, I would indeed use the format <package>-<version>. The reason for the “asynchronicity” is a fix of the cli package that only afflicted that package and none of the others. As soon as we hit 0.7.0 I'll align all the versions again.