Release strategy

[jankapunkt]

How do we want to release a new version?

• who should release? -> human vs GitHub Actions?
• when to release?
• how to prepare a release? -> one release branch with tags or one branch for each major version? like release-4.x, release-5.x
• do we want additional tests that run in GitHub actions when merging to a release branch? GH Actions is so flexible I could even clone another repo and install the intended release package into it and run tests, so we can test adapter-compliance and even the example repo if we want. There are no limits :-)
• who is responsible for release management and the deployment keys, npm repo etc.?
• do we also want to release to GitHub packages as a redundancy factor?
• what else....?
• do we want to hold these information in a `MAINTAINERS.md? ?

[jankapunkt]

So I checked a bit into GitHub actions again and they provide a secure way to deal with deployment secrets: https://docs.github.com/en/actions/security-guides/encrypted-secrets

The advantage here is, that we could trigger a deploy action, once a PR is opened to merge into release or master we can run

• basic tests (as we already do with every PR)
• extended tests (adapter impl using the new release, examples using the new release, maybe pentests?)
• additional security scans (npm audit, static code analyses using GitHub CodeQL)
• npm publish dry-run using the deploy keys

then once finally merged into this specific branch we can start another action, that

• tags the commit with release-<version>
• finally runs npm publish using the deploy keys
• creates a release on GitHub as well

Advantages:

• less error prone, since automated
• no relying on a single human to release a new version (imagjne the person responsible for deploy is sick at home or on vacation)
• if we abandon we can leave the deploy keys for the upcoming maintainers

Disadvantages:

• we need to tighten access restrictions to the release branches as good as possible (maybe PR to this release-branch must require 2+ approved reviews and can only be opened by maintainers?)

[oklas]

Excellent considerations. I would be glad to work on this and continue developing the release process based on the commit message (the ideas that I suggested in #32).

[jankapunkt]

@HappyZombies can you add @oklas to the maintainers? I unfortunately can*t

@oklas that would be great! Are you familiar with dependabot and github actions? I am so half-half (used both in my projects and read the docs but skipped many sections that I thought irrelevant at that time). I think we can make huge progress just by getting to know how both actually work:

https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates

https://docs.github.com/en/actions/publishing-packages/publishing-nodejs-packages

[HappyZombies]

@jankapunkt I think I want to hold off adding maintainers right now, unless adding oklas will bring great value? If he wants to contribute he can just write PRs.

I don't see how adding more people as maintainers and giving them write access will help right now, I think we are doing good with us 3, and another might be a too many cooks in the kitchen situation.

Also because of what @jwerre #16 (comment) mentioned, we don't wanna just add maintainers willy nilly (if I am being honest I took a risk with adding you both and I don't wanna keep taking risks lol)

[jwerre]

(if I am being honest I took a risk with adding you both and I don't wanna keep taking risks lol)
🤣

[jankapunkt]

@HappyZombies allright no problem I can totally understand this it's all risky for all of us involved (at least when running this in production)

Well, then let's first go through the proposed release strategy and see if you and @jwerre have any further thoughts on this.

[oklas]

"Just write PR" can only be done for just code and tests. Working on things like config and interacting with third party services tuned to a specific repository or branch requires access to the repository and branch and third party services. Therefore, the first way is to set up a similar complex of systems in another repository, which means not just a fork, but a complex of interconnected systems. And the second way is a membership, which @jankapunkt suggested. And of course, permanent work is much more convenient and efficient from the inside.

[HappyZombies]

@oklas I just realized you were the same person that e-mailed me personally asking to be added as a maintainer.

I can understand that it's good to be on the "inside", but we JUST got started and we are starting with updating the out-of-date dependencies and removing / fixing major issues. Besides I am not even sure what third party services we need or IF we need any at the moment, that's something we haven't even discussed yet nor are no where near.

Whenever we get to that point and if/when we grow more, I will gladly add you as a maintainer next, but at the time being, I really don't see the need to add another maintainer. You can help by writing PRs, because that's all we need right now.

I hope you don't take this the wrong way, I just want to be very careful moving forward, this is our break or make moment and I want to tread carefully.

[HappyZombies]

@jankapunkt let's move forward with publishing using GH Actions. https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry

[jankapunkt]

@HappyZombies @jwerre we definitely need to add 2nd factor on the NPM repo as countermeasure against supply chain attacks, which just happened with ua-parser-js

Then we can also automate releases, because a realease-attempt will have to pass the 2nd factor and makes it harder to release a hijacked package in case one of our GitHub accounts is compromised.

Do you guys have actually 2nd factor on your GH accounts active? Same goes for PGP for commits (you can see that through my commits are "verified") -> it presents someone simply commiting code on your behalf even if they know your password / hacked your account.

[jankapunkt]

In case you didn't noticed already: faisalman/ua-parser-js#536

[jwerre]

@jankapunkt I do have two-factor active.

[jwerre]

In case you didn't noticed already: faisalman/ua-parser-js#536

Thanks for the heads up on this!

[HappyZombies]

@jankapunkt and @jwerre for sure two factor is very important to have not just in GitHub but in NPM too!

I think we can also look into adding PGP for commits, given things like the ua-parser-js incident.

[HappyZombies]

@jankapunkt I just checked the organization settings, enabling two factor will actually kick you out of the org. Mind enabling two factor for you GitHub account before I make this change?

[jankapunkt]

Yes let me do this tomorrow morning, I will ping you once completed

[jankapunkt]

@HappyZombies done, please check again

[HappyZombies]

Closing since we are done here and also due to #121