Change pre-release (beta, rc) publishing strategy

[agubler]

The beta1 period has allowed us to learn about how we should publish our pre-release packages and highlighted that what we have right now isn’t ideal. As continually publishing to beta1 is not manageable and doesn’t give us (or the community) the safety that tags are supposed to give us (as beta is basically a moving target).

The proposal is to stop publishing to beta1 now so it will become the “finished” beta1 release-set. From now until we are ready to cut beta2 we will publish to next with all of our packages depending on the next tag. At the point in time when we are ready to tag the beta2 release-set we’ll branch from master, update the dependencies (to beta2), publish (in dependency order, has upwards) and tag the final versions to beta2 and latest. We will repeat this process for our future beta and rc releases. This means that pre-release tags will always point to the end of the phase, latest will always point to the latest pre-release tag’s version (so that npm install @dojo/widget-core installs the latest “stable” version) and then next will effectively be master/development.

Nothing really will change for our internal development, just need to produce a first release of the -beta2 suffix and tag it against next for all the packages (updating the package.jsons also).

Todo:

For each dependency, in order:

1. Update dependencies to point to next tag
2. Release/publish first 2.0.0-beta2 version for next tag

Ensure all packages latest and beta1 tags point to the same version.

• dojo/loader
• dojo/has
• dojo/shim
• dojo/interfaces
• dojo/core
• dojo/routing
• dojo/i18n
• dojo/widgets
• dojo/widget-core
• dojo/cli
• dojo/cli-build
• dojo/cli-test-intern
• dojo/cli-create-app

[dylans]

Should https://github.com/dojo/cli-export-project also be on this list? (and really any other packages like https://github.com/dojo/dgrid/ that rely on beta1 but are not beta1 themselves)?

[agubler]

@dylans It's a good question, dgrid can be updated to next if we want it to benefit from the bleeding edge changes in widget-core but equally we can stay on the beta1 tag if we want to choose when to take in the changes (some that would be breaking).

[agubler]

Same applies for @dojo/widgets, but I did create a pull request for widgets.

[kitsonk]

We have pretty much resolved this right? Or at least I believe I understand the strategy. Do we want to just hold this open until we cut beta2?

[agubler]

@kitsonk I'm happy for this to be closed if others are also.

[jason0x43]

Just throwing this out there... I think we should avoid using dist tags as dependencies since they 1) cause npm to emit spurious warnings, and 2) they break the versioning contract (this is especially problematic with 'next', which could point to different major versions over time).

[kitsonk]

We have a new strategy that we used for beta3. This issue is effectively closed. We should open any follow up actions required as a new issue.