Publish @carbon/ibm-cloud-paks npm module

[SimonFinney]

Acceptance criteria to be defined in GitHub by owner in collaboration with group

[lee-chase]

Publishing/modifying npm packages is restricted to owners. There is only one level of access.

https://docs.npmjs.com/cli/owner

A list of owners for carbon-components-react, for instance, is as follows. It is of note that they have a carbon-bot email address which I suspect is for automated publishing. Confirmation will be sort from @joshblack

$npm owner ls carbon-components-react abbeyhrt Abagail.Hart@ibm.com adavila adavila91@gmail.com carbon-bot carbondesignsystem@gmail.com dakahn da.anguiano@ibm.com emyarod afw5059@gmail.com jnm2377 josefinanoemi4@gmail.com joshblack joshblack@us.ibm.com tjegan tj.egan@icloud.com vpicone vp@vincepic.one

[lee-chase]

Without an automated build (as is the case for @carbon/vue) 'lerna publish' can be used to manage the publication of multiple packages from a repo.

https://www.npmjs.com/package/@lerna/publish

[joshblack]

Let me know if we can help out with this, if publishing from CI we can provide an NPM_TOKEN for the carbon-bot.

Similarly, we can create a group of users under the @carbon scope and give them access to the relevant packages.

Lerna is a great tool for publishing, especially with the conventional commit flag. Let me know if you want to chat about it at all!

[SimonFinney]

For the first release, I'd be happy with enough configuration that enables us to automate the publishing of a package and tag based on conventional commits.

[joshblack]

@SimonFinney very nice, lerna version has a --conventional-commits option for this: https://github.com/lerna/lerna/tree/master/commands/version#--conventional-commits

Similarly, you can use --conventional-prerelease and --conventional-graduate for a prerelease workflow.

It should help generate relevant tags and release changelogs (and CHANGELOG.md files) too!

[lee-chase]

There's also the option to use lerna publish, which includes a call to lerna version from the command line to publish to npm.

[SimonFinney]

@carbon-design-system/ibm-cloud-paks See https://github.com/carbon-design-system/carbon/blob/master/docs/guides/endgame.md for how we might want to model our release process

[joshblack]

@SimonFinney if it helps out, we simplified a bit from that end game process to basically the following:

• We follow 2 week sprints
• We're on a time-based release cycle
• Every other week (the second and fourth of each month) we do a minor release
• In between minor releases, we can still patch or do hotfixes in a patch release
• Before every minor release, we ship a Release Candidate for a sample of teams to verify

One flow that we used before (that unfortunately is busted because of a lerna challenge we have) is a nightly release flow (published under the nightly tag) that is a nice complement to the time-based cycle for teams that want to stay up-to-date (or if we want teams to help with experimented with stuff)

The last part of this process is that our "release team" cycles every month. The release team has two members, a lead and a side-kick. The lead owns the release along with training the side-kick. They are also on-deck for handling any release-related problems reported on GH or Slack, alongside determining release scope (what should / should not go into a release)

[SimonFinney]

Thanks @joshblack ! That certainly helps simplify it - So far, my current thinking is:

• Time-based minor releases at a minimum once a month
• Hotfix and patch releases in-between minor releases where necessary
• A release candidate cut the week before a minor release for verification

For the short-term, I was thinking we could just publish on every merge to master and figure out any additional channels, configuration, and steps when required.