Cutting a Release

[yordis]

hey, @beam-community/team I am trying to get up to speed and maintain a bit of the package health (I am personally now using it as well), so I wanted to cut a release but:

1. I am not sure if I can use the deployment workflow yet (I need to test it, would dry-run work to test if we have the right permissions? I am scare to try 😄)

2. MOST IMPORTANT I need your support assessing what version should be released.

Check the release so far: https://github.com/beam-community/stripity-stripe/releases/edit/untagged-6b1018753b42067415d6 please give us a few minutes to assess the changes.

@snewcomer most of the big changes came from you in one way or another, so I would appreciate if you help me here.

[yordis]

@doomspork could you help me over here?

[cgarvis]

any word on cutting a release?

[yordis]

Sorry, peeps are busy lately. I am going to continue the work once they unblock me.

[btkostner]

You should be safe to create a new release. The deployment workflow will automatically trigger when a new release is published and it will pass (hopefully yay!) or fail, which won't cause any harm.

I'm not sure the best version for this though.

[onegrx]

Are you going to make a release soon?

[yordis]

Firstly, I must say, the package's recent introduction of the feature to code-gen the entire SDK from the OpenAPI is truly exceptional! It's this sort of invention that motivated me to help the new EEF working group focusing on OpenAPI generators for prevalent packages and close the topic together across the ecosystem; by now, I have seen it all, I believe.

However, I've observed a potential issue and I'm hoping we can brainstorm solutions together. It appears the process goes directly from file to final code at compile-time, without a clear verification step for the generated code. This brings up a couple of concerns:

1. Assisting others when an issue arises becomes a bit challenging. If something doesn't go as planned, there's no specific line of code users can point to for help. The stack trace only provides meaningful insights if I possess the same SDK version they generated.

2. Online documentation currently seems to lead to dead ends. Most of the GitHub links appear broken, primarily because the compiled code from the file isn't checked in, which affects the overall usability.

I'm interested in understanding the reasoning behind this approach and why the decision was made to avoid checking in the code-gen code, relying instead on compile-time.

More importantly, I'm curious to know your thoughts on possibly reconsidering this decision. We could still make good use of the code-gen tool, but perhaps we could consider outputting the code and checking it in, as a way to address the concerns I've raised.

I genuinely respect and value your decisions, and my intention is simply to help mitigate any potential issues moving forward.

In my experience, finding a middle ground often yields the best results. I would love to hear your thoughts on this matter.

Looking forward to your feedback!

[yordis]

@beam-community/team I need your direction here, I wouldn't like to feel bad for making a decision that then backfires on me. I have my opinions but I know the combined thoughts will produce a better outcome.

Please help 🙏🏻

[maartenvanvliet]

I'll chime in here to detail some of the history.

I wrote https://github.com/maartenvanvliet/striped which is a Stripe SDK in Elixir. Originally the goal was to write a library with the building blocks to generate SDKs based on OpenAPI specs but I never got around to that. Turns out many specs are subtly different enough that custom code is needed for every one to get the best client out of it. So, I just kept it to Stripe.
The code-gen in my library is also straight to compiled code, inspired by this repo https://github.com/wojtekmach/openapi/tree/master and it did what I needed it to do.

Much of the code in my library ended in this repo after a discussion, though with changes to keep some compatibility with how Stripity-Stripe worked in v2. So that's how we end up here.

Back to the issue, I can totally see your view that the compiled approach makes it harder for maintenance and debugging issues. Checking in generated code would definitely help here.

Going forward I see two approaches:

The first one is to write the currently generated code to disk. My initial goal for my building blocks library was to add this as an option as well. Downsides are that the generated code is not very idiomatic. Lot's of unnecessary parens for example but also the generated code relies on stuff being evaluated at compile time. These end up as if false do in the module body so it'll be compiled away but not very nice to read.
It'll be very quick to get this up and running.

The other approach is to use string templates. This gives complete control over the output but would require some changes in how code is generated.

My preference for now lies with the first approach, mostly because it makes it easier for a release to be made soonish. I can make a PR if you wish.

I'll see if I can help out with some of the open issues.

[yordis]

Seeing the SDK generation is encouraging, even if it might not be perfect yet. After all, what truly matters to us is sparing everyone from the laborious process of hand-writing the client and ensuring a positive developer experience. As for the current quality of the code-gen, it's not my primary focus.

I genuinely value and care about seeing the tangible output saved to the disk and committed. That progress is significant to me!

I can make a PR if you wish.

If you know how to accomplish the most basic "write-to-disk", by all mean help me here!

[yordis]

Because of #776 I am cutting a v3

I hope I do not get backlash, too long without releasing, too many changes, and the original author isn't available to own the situation.

I am trying my best to help you all.

[yordis]

https://github.com/beam-community/stripity-stripe/actions/runs/5925955972/job/16066421114#step:6:369

account not authorized for this action

@beam-community/team hey, we can not publish to Hex. I am not sure how to help here!

[yordis]

A good idea to fix #800 before cutting off a v3

[yordis]

Folks, I can not publish to Hex still, I need help here @beam-community/team

[yordis]

@begedin @snewcomer, it seems you are owners of the package, so you may be able to help here 🙏🏻

[snewcomer]

Done @yordis!

[justindotpub]

Thank you for the release! ❤️ ❤️ ❤️