Policy around npm tags

[mpetrunic]

Current situation:

• We can probably straight on delete "next" tag as 2.x is definitely not next nor supported.
• We also don't need alpha since we cut rc version of 4.x
• If we add canary releases to 1.x we could remove rc tag as well

Proposal

I would propose in the future that we stick to following tags:

• latest - latest stable version
• dev - latest canary version
• legacy - latest 1.x stable version
• legacy-dev - latest 1.x canary version

When necessary, we can tag specific canary versions with rc (4.x) and rc-legacy (1.x)

[jdevcs]

Thanks this is very good to introduce canary version.

Could we decouple tags from versions? As in case of inevitable breaking changes in 4.x , if we bump major and still want to keep alive few older versions.

[mpetrunic]

Thanks this is very good to introduce canary version.

Could we decouple tags from versions? As in case of inevitable breaking changes in 4.x , if we bump major and still want to keep alive few older versions.

For sure, eventually when we start working on next major, we would use legacy for 4.x and latest for 5.x. That said plans for 4.x are to promote it to LTS in which case we might decide to drop "legacy" tag and use "lts"

[Muhammad-Altabba]

Hello @mpetrunic and @jdevcs
Regarding 2.0.0-alpha.1 that is marked as next. Is it safe for someone with the right permissions to delete the next tag?
Thanks,

[Muhammad-Altabba]

And I vote for deleting the alpha tag.
But I strongly suggest keeping the rc. And I think we should have something like an independent QA team who should provide a Quality Assurance Certificate, on each RC, before that RC version can go into being called a release.

[mpetrunic]

Deleted next. Trying to delete alpha and rc tags (hitting rate limit 🤦🏻‍♂️ )
For reference one-liner to do it npx lerna exec --stream --no-bail --concurrency 1 -- 'npm dist-tag rm $LERNA_PACKAGE_NAME next --otp <your otp>'