Protobuf.js: Cutting a release

Created on 1 Feb 2020  路  7Comments  路  Source: protobufjs/protobuf.js

Greetings folks! I'd like to be able to cut a release if possible. After we have a new release or two out, and stabilized, I'd also like to start automating releases so we're not dependent on any individual to keep things going, rather group owned credentials.

  • Is the process for cutting a release documented today? I see npm run release, which appears to create a tag and compiled assets. It's unclear how this dovetails with running npm publish.

  • Would it be possible to add google-wombot as an admin on the protobufjs package on npm? Alternatively, could we add justinbeckwith, fenster, or bcoe so we have someone with admin?

  • Would it be possible to expand the list of users with admin on the repo, to include JustinBeckwith, alexander-fenster, and bcoe, so we can set up a little more automation?

@dcodeIO - I realize this is askin a lot, but we really do want to make sure things can keep rolling here, especially dependency updates :)

@alexander-fenster @bcoe as FYI

Most helpful comment

Heh, that PR alone was enough to trigger some bitter sweet nostalgia, ultimately leading to a journey through the code I once cared for so much, at a time when I was overly optimistic that stuff will pay off one way or another some day. Still wish I had a month or two to sink into the repo to modernize it, but well. I guess my adventures so far have made me more of an expert in making software that isn't sustainable and will ultimately rot than I've become the expert I once went to become. And yeah, right now this makes me question a lot more than it should, ignore me :)

That being said, I've added google-wombot to all the relevant packages on npm, made JustinBeckwith and alexander-fenster owners of the protobufjs org, and invited bcoe.

All 7 comments

would love to pitch in as best I can, I've been using the automation machinery our team has been building on projects I manage, such as yargs.

There isn't really a release process in place as of today. Mostly a bunch of scripts to do it manually, with npm run release being a shorthand to run all the relevant tasks before issuing a publish.

I'm open to your suggestions and google-wombot seems like a great tool. An alternative might be to do something like we do over at AssemblyScript, which is solely based on GitHub Actions, not much more than a few lines of GH actions code. Publishes nightlies once a day if there have been changes, respectively creates releases if the version in package.json changes.

Both approaches sound awesome to me - the biggest thing I'd like to see is automation so we don't have to bug you :)

I take the semantic-release release approach in my projects, which cuts a new release _every time_ a relevant PR is landed. You cna see an example of combining that with GitHub Actions here.

That could be heavy handed for some, which is why I like the release-please approach that queues up PRs with the changelog, and lets a maintainer merge them for the machinery to kick in. The nightly approach also sounds great. Anything that gets us automation basically lol.

While looking into this, I started wondering what to do with the support packages in lib/. These are currently independently versioned and would need some special logic. The easy route would be to make these use the exact version of the main package and publish these even if there haven't been any changes, but that'd create a lot of unnecessary publishes since these rarely change. How would you tackle this?

Other than that, I set up the integration so far that there's an NPM_TOKEN (of the protobufjs acount on npm with access to all the packages) in GH actions that can be used for publishing now and once everything is sorted out should be as easy as removing Travis-CI and putting the workflows into place.

@dcodeIO if you want to bring it to email bencoe @ google.com, I think I could help you plug in some of the automation we've been working on for the community. The only caveat is a slight change in how commit messages are written (moving to conventional commits). I'd be happy to help with the infrastructure so that:

  1. it's still published under whatever account you'd like to use, but.
  2. has an automated draft PR for releases using release-please.
  3. has 2FA enabled.

Heh, that PR alone was enough to trigger some bitter sweet nostalgia, ultimately leading to a journey through the code I once cared for so much, at a time when I was overly optimistic that stuff will pay off one way or another some day. Still wish I had a month or two to sink into the repo to modernize it, but well. I guess my adventures so far have made me more of an expert in making software that isn't sustainable and will ultimately rot than I've become the expert I once went to become. And yeah, right now this makes me question a lot more than it should, ignore me :)

That being said, I've added google-wombot to all the relevant packages on npm, made JustinBeckwith and alexander-fenster owners of the protobufjs org, and invited bcoe.

This is working great now, with auto-releases and all such things. Closing :)

Was this page helpful?
0 / 5 - 0 ratings