-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
I thought I did that (manually), but it turns out I didn't. I'll add tags after-the-fact now. Using |
Also, @ftomassetti : I think it's inevitable to have one tag per package ( |
As we publish packages separately, we need a tag per package indeed. This is different from the |
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 |
Yes, I would indeed use the format |
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.
The text was updated successfully, but these errors were encountered: