Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using changeset to organize releases #149

Open
ftomassetti opened this issue Apr 10, 2024 · 5 comments
Open

Consider using changeset to organize releases #149

ftomassetti opened this issue Apr 10, 2024 · 5 comments
Assignees

Comments

@ftomassetti
Copy link
Contributor

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
Copy link
Contributor

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 dslmeinte self-assigned this Apr 10, 2024
@dslmeinte
Copy link
Contributor

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

@joswarmer
Copy link
Contributor

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

@ftomassetti
Copy link
Contributor Author

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
Copy link
Contributor

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.

@dslmeinte dslmeinte changed the title Consider adding tags for each release Consider using changeset to organize releases May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants