Publish @carbon/ibm-cloud-paks npm module about ibm-products HOT 10 CLOSED

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!

from ibm-products.

@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!

from ibm-products.

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

from ibm-products.

@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)

from ibm-products.

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.

from ibm-products.

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

from ibm-products.

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 [email protected]
adavila [email protected]
carbon-bot [email protected]
dakahn [email protected]
emyarod [email protected]
jnm2377 [email protected]
joshblack [email protected]
tjegan [email protected]
vpicone [email protected]

from ibm-products.

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

from ibm-products.

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.

from ibm-products.

@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

from ibm-products.