Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

libraries: Pre release checklist #88

Open
zekth opened this issue Dec 30, 2023 · 2 comments
Open

libraries: Pre release checklist #88

zekth opened this issue Dec 30, 2023 · 2 comments

Comments

@zekth
Copy link
Member

zekth commented Dec 30, 2023

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:

standard-webhooks/libraries/javascript/package.json

Line 5 in 569dcd4

"author": "svix",

Urls

Lot of libs target strandard-webhooks/libraries.git which is now invalid. ref:

standard-webhooks/libraries/java/gradle.properties

Line 6 in 569dcd4

POM_SCM_CONNECTION=scm:git:[email protected]:standard-webhooks/libraries.git

Release flow

Currently the release flow is for v* tags (ref:

standard-webhooks/.github/workflows/csharp-release.yml

Line 6 in 569dcd4

- "v*"
)
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
@tasn
Copy link
Contributor

tasn commented Jan 1, 2024

  • 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?

@zekth
Copy link
Member Author

zekth commented Jan 1, 2024

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.

@zekth zekth mentioned this issue Jan 1, 2024
Merged
tasn pushed a commit that referenced this issue Jan 1, 2024
@zekth
fix(libs): metadata (#89)
449485c 
Address the issues with libraries metadata regarding Author and links. I
think everything has been adressed correctly.

Ref: #88
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tasn @zekth