Repository navigation
Proposal: Add tag to version #249
Description
Affected Packages
cli, probably apply-release-plan
Problem
With independent versioning, it's not clear what you need to upgrade when a release is done, since the version of each package is separate. For example, if I version [email protected] and [email protected] and [email protected] in one run of the version command, but all are linked in including the same security, patch, knowing this list of versions when upgrading (as a consumer) is very useful.
Proposed solution
Leverage tags in npm when publishing to name a release:
changesets publish --tag=one
changesets publish --tag=heather
This will allow consumers to:
yarn upgrade pkg-a@one pkg-b@one pkg-c@one
or if names are used:
yarn upgrade pkg-a@heather pkg-b@heather pkg-c@heather
Being able to publish with tags isn't necessarily a huge change.
Relevant related thing, some people using changesets already name their releases. It would be good when running 'version' to also provide this tag. This relates to #200 - it's possible you just pass this in twice, but it would be good if that wasn't necessary.
Activity
danieldelcore commentedon Jan 17, 2020
This is a great idea, i love it!
Some ideas/ notes:
Noviny commentedon Jan 17, 2020
Some further thoughts around this:
It's worth noting that running
npm tagmay need to be run separate to publish, as we also want ti published to 'latest'The pro of this is upgrading all packages from the monorepo is the same each time, vs needing to hunt down specific versions. Both can work from an automation perspective though, so maybe it's not that important.
In auto-publishing, we need to think about how tags are passed in. Whether this is something changesets would want to own, or whether it's an implementation detail for the automator.
emmatown commentedon Jan 21, 2020
I'm not sure I understand the use case for this. Why does knowing the versions/having a special tag for it matter? Wouldn't knowing the packages that you need to update be enough(especially given that you already need to know that even if you have the tag) so that you can do this:
Noviny commentedon Jan 21, 2020
it is if you assume you are always moving to latest, but we've got a fair number of cases where someone wants to upgrade to a moment-in-time, but not pass beyond that moment-in-time. The current strategy is effectively list the version of each package at that moment. This allows us to apply an arbitrary name to that moment to remove the need for such a list.
So, the explicit goal is "I want to upgrade to a moment-in-time release of packages from a monorepo, but I do not know what versions existed at that moment"
thekevinbrown commentedon Apr 6, 2020
Also @mitchellhamilton, there's the case where let's say that (hypothetically) Keystone v8 doesn't work with Node 10, but I have to stay on Node 10 because of infrastructure reasons. In this case, I either need a table of Keystone v7.0.1 is compatible with Knex Adapter v6.0.0, and v7.0.2 is compatible with Knex Adapter v7.0.0, for every single package in the monorepo, or I have to look at publish times and guess, then hope I haven't introduced a subtle breakage that I don't notice between packages that aren't compatible.
There have been quite a few people on Slack confused recently because the versions of the packages don't line up (e.g. I've got Keystone 7, where is Admin UI 7?), and if there were a consistent way of getting all the packages that worked together that aren't the latest, this'd be hugely helpful.
Noviny commentedon Apr 6, 2020
Just capturing some notes from an internal discussion around this as it looks like this will be implemented soon:
There will be a new config option for
getNextTagName, which will behave similarly to the changelog generators, provide a function and maybe options.I'll make a default one that just goes through a list of names and uses the next one in the list.
The
latestTagwill be written back after versioning. Unsure what file to add it to (is modifying the config okay??). The next call ofpublishwill use the tag.Names here are very draft.
This feature will be off by default - I am aiming for this to be a minor change.
Below are unfiltered release notes
Opinion on where combined release notes live? `[release-notes.md](http://release-notes.md)` or `[changelogs.md](http://changelogs.md)` in rootSO how does this affect changesets?
Change to
versionChange to
publishnpm dist-tag add package@latestlatest tagWhat config do we need?
We need the last release
We need a list of releases (where we can look up the next release) releaseTagKeyThing ||
trueconfig the release goes to is customisable
What happens if a tag name appears twice?
Question: what happens if there is no next thing?
Noviny commentedon Apr 6, 2020
For helpfulness, going to go with
getNextReleaseNameandlatestReleaseas the new keys, as the fact they add tags somewhere isn't the relevant thing.Noviny commentedon Apr 15, 2020
Big thing that needs to be talked about above: How often do you iterate the tag name?
Important thing is often you want to patch the
latestTag, not create a new tag. This needs to be pretty seamless.Need to run some experiments on how to do this.
Andarist commentedon Sep 15, 2020
@Noviny how this relates to the new
manypkg npm-tag?Noviny commentedon Sep 15, 2020
Probably closing this while experimenting with
manypkg npm-tag- That was intended to be a less intrusive lighter weight way of achieving the same objjectives.jorenbroekema commentedon Jun 7, 2021
We actually kinda need this feature, are you still planning to implement this?
What is the workaround right now, do a manual
npm dist-tag add <package-name>@<version> [<tag>]on post publish in a script maybe?jorenbroekema commentedon Jun 20, 2021
I just realized my proposed workaround wouldn't be sufficient.
Imagine publishing @foo/[email protected] , it will get the "latest" npm dist tag.
Then publish @foo/[email protected], it will get the "latest" npm dist tag.
So even if you then do
npm dist-tag add @foo/[email protected] one, you're still stuck withlatestpointing to the wrong thing. You may be able to configure something yourself that restores thelatestdist-tag back to the correct thing again but it's definitely some effort :\The use case for this is as follows (also illustrated by the scenario above): we have a latest (major v2) and a legacy branch too (major v1). Sometimes we find bugs that have to also be fixed on v1 so we have to publish a new version of our legacy (major v1).
dist-tags make it easy to ensure that
latestis always pointing to v2, by ensuring you publish to dist-tagv1for example orlegacywhen you publish a new patch or minor on major v1.