Consider using npm distribution channels for early access releases

[lance]

Is your feature request related to a problem? Please describe.
Currently it is difficult for users to test changes on main without a published module. We often go months without a release, which can make it hard for users to keep up with changes as they are happening.

See: #385 (comment)

Describe the solution you would like to see
Use npm distribution channels to provide early access to the module as, for example, cloudevents@canary. This would also entail modifying our publishing process via release-please, or some other defined process to determine how and when to publish a module. If this is to be automated, there is an unfortunate side effect in that we will need to provide npm publishing credentials to the repository config.

Additional context
npm distribution channels: https://docs.npmjs.com/cli/v7/commands/npm-dist-tag
some background: https://docs.npmjs.com/cli/v7/commands/npm-dist-tag

[lholmquist]

+1 to using the canary tag.

I know npm now has the "automation tokens" that can be enabled, https://github.blog/changelog/2020-10-02-npm-automation-tokens/, but haven't used them yet.

I guess in my mind, we would publish to the canary tag after every merge(automated with some action), but would still want release-please to create a PR for the "next real release" which we would merge manually when it is time for a releae like we are currently doing

[github-actions]

This issue is stale because it has been open 30 days with no activity.

[lance]

@lholmquist I started to look into this, and it's not clear what the best way to determine the next version should be. The release-please library and action don't expose a way to determine what the next version is. We could write code to look at the current version in package.json, then bump it according to conventional commit rules, based on iterating over the commits since the last release. But that seems like something that someone must already have written, and duplicates a lot of the release-please capability.

[lholmquist]

it's almost like there should be a "prerelease-please" action :)

i'm sure we could write something based on convential commit rules, i'm pretty sure there is an api we can use. Just thinking out loud here, but i don't htink we would want to merge back into main those pre-release commits, so getting the current pre-release version and bumping it to the next appropriate one might be interesting.

[github-actions]

This issue is stale because it has been open 30 days with no activity.

[PSanetra]

Just as a hint to tooling: I have written a cli tool that also supports prerelease counters: https://github.com/PSanetra/git-semver#examples-1
The next version is calculated based on previous git tags and recent conventional commits.

[github-actions]

This issue is stale because it has been open 30 days with no activity.