libraries: Pre release checklist
zekth opened this issue · comments
Before starting to release the libraries we need to address some areas and workflows.
Content
Author
Currently some packages have author field set as Svix; i assume that was ported from the initial project created by Svix but i'd say we should change this to standard-webhooks. wdyt?
ref:
Urls
Lot of libs target strandard-webhooks/libraries.git which is now invalid. ref:
Release flow
Currently the release flow is for v* tags (ref:
However it creates friction for several reasons:
- golang uses git tags for versionining which for our case will need to be
libraries/vX.Y.Z - What happens if there's a security bump on one library and not on the others? Do we trigger a release for all revisions for a patch?
I'd propose a strategy that each library has an independent versioning regarding PATCH releases but MINOR and MAJOR should be released at the same time, meaning all libraries should offer the same API to be able to be released.
Any idea welcome
- Author: oops, yes, let's fix it.
- Urls: also a remanent of the past, let's fix.
- golang uses git tags for versionining which for our case will need to be libraries/vX.Y.Z
This sounds reasonable.
- What happens if there's a security bump on one library and not on the others? Do we trigger a release for all revisions for a patch?
I say: let's just sync them all. Patch changes in different libs should be relatively rare given the surface area (they are small), and even when they happy there is no real harm in having a version bump that doesn't change anything. I think that in most cases if you change one you probably change all anyway.
On the other hand, maintaining different tags (or repos) for each library is a pain. We (Svix) moved from a repo per lib to just having them all in one repo with sync versions because it was a pain to have them separate (relevant repo: https://github.com/svix/svix-webhooks). I think the different tags is almost the same pain as having multiple repos.
What do you think?
I say: let's just sync them all. Patch changes in different libs should be relatively rare given the surface area (they are small), and even when they happy there is no real harm in having a version bump that doesn't change anything. I think that in most cases if you change one you probably change all anyway.
On the other hand, maintaining different tags (or repos) for each library is a pain. We (Svix) moved from a repo per lib to just having them all in one repo with sync versions because it was a pain to have them separate (relevant repo: https://github.com/svix/svix-webhooks). I think the different tags is almost the same pain as having multiple repos.
I'm fine with the approach, as long as it's clear that everything will be bumped regarding patches potentielly not updating the given lib; like a security bump on golang and lead into noop in javascript.
regarding the tags, do we have a separate tag for golang or do we have tags for libraries and tags for specs? Potentially a vX.Y.Z tag can also generate a libraries/vX.Y.Z tag required for golang.