Figure out branch pattern/workflow for publishing releases to npm

[jaeddy]

... and add logic to TravisCI config.

[jb-adams]

@jaeddy does this include automated npm publishes upon version number increments in package.json? If so, we could do something with Github Actions, whereupon every time we merge a release branch into master we trigger a publish, or something to that effect.

As an aside, it might also be good to release some of these workflow/build processes we're learning as a guide in TASC.

[jaeddy]

@jb-adams - yep. The automation itself should be relatively manageable with GH Actions, TravisCI, or whatever other system. The "flow" and conditions on which releases are created and published feel a bit trickier to me. Maybe we go with Hubflow, as that seems to be the preferred choice for Cloud WS products... in which case the exercise of implementing should hopefully be pretty straightforward.

Agreed re: TASC — especially with GitHub now supporting workflow templates for Actions. I guess that raises a related question: is GitHub itself a prescribed standard for GA4GH (versus Bitbucket, GitLab, etc.); what about CI/CD frameworks?

[jb-adams]

I don't know of any GA4GH products/projects that aren't tracked in GitHub and aren't built/tested on Travis, so while it may not be prescribed yet, it's definitely a mainstay. I think this falls under the realm of Guides (we recently fleshed out our strategic roadmap, the gist of it is that we have different product types, ie. Technical Specifications are different from Policies are different from Guides and Resources). So if we put together a 'Best Practices flow for maintaining GA4GH specifications' guide I think that's perfectly valid, and TASC (or somewhere else in GA4GH) can host the documentation.