-
Notifications
You must be signed in to change notification settings - Fork 3
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.
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
ci: setup initial release process #23
Conversation
Signed-off-by: Michael Beemer <[email protected]>
providers/openfeature-flagd-provider/lib/openfeature/flagd/provider/version.rb
Outdated
Show resolved
Hide resolved
providers/openfeature-sdk-meta_provider/openfeature-sdk-meta_provider.gemspec
Outdated
Show resolved
Hide resolved
providers/openfeature-sdk-meta_provider/openfeature-sdk-meta_provider.gemspec
Outdated
Show resolved
Hide resolved
Signed-off-by: Michael Beemer <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not familiar with release-please, what is the intended workflow? For release please to maintain a PR as described on its repo that once merged will proceed with the release?
Will it require that each provider gets released at the same time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@beeme1mr I'm glad this is a forcing function to address the naming inconsistencies we have. Here's some thoughts:
- Conventionally in Ruby, you'll see snake_case files map to PascalCase constants. So, if we want the
OpenFeature
to be our top-level module, you'd expect every path to beopen_feature
. We've been talking about this in this issue on the SDK. My preference is we do that here. - This runs into an issue with the SDK artifact we're currently releasing.
openfeature-sdk
would result in an expected constant ofOpenfeature::Sdk
. Most folks will conventionally know thatSdk
should be inflected toSDK
, so that's fine, but the top-level module is still named unexpectedly. I have thought that it might make sense to rename the primary package toopen_feature
before we release1.0
(also dropping SDK because I don't think it adds value for us), but I didn't know how much will there would be for that. - Bringing that all into these gems, I think my desired naming would be
open_feature-meta_provider
andopen_feature-flag_d
(ofopen_feature-flag_d_provider
if we're only shipping a provider). That matches gem naming conventions where the-
indicates that something is modifying/plugging into another gem and has the expected casing. - I am but one voice in this, and happy to have the discussion. There's plenty of non-conventional gem names/module pathing and it's fine as long as you explain usages in your README.
providers/openfeature-sdk-meta_provider/lib/open_feature/sdk/provider/version.rb
Outdated
Show resolved
Hide resolved
Signed-off-by: Michael Beemer <[email protected]>
Signed-off-by: Michael Beemer <[email protected]>
Signed-off-by: Michael Beemer <[email protected]>
Signed-off-by: Max VelDink <[email protected]>
Signed-off-by: Max VelDink <[email protected]>
0a5866d
to
0228eab
Compare
Signed-off-by: Max VelDink <[email protected]>
fddd62f
to
ebfdc00
Compare
@beeme1mr I made some modifications to the naming for the meta_provider (and I'll have some follow-on changes in the ruby-sdk). I like the place we ended up 👍🏻 |
Awesome, looks good to me! Are we good to merge? If this works, it should create release PRs, and merging those PRs should do everything except publish the Gem. If that goes smoothly, I think it should be pretty straightforward to finish up the publishing step. |
Yep! I'll try and merge this in first thing tomorrow. |
This PR
Notes
This won't actually publish the Gem but includes all the plumbing.
Follow-up Tasks
How to test
We'll do it live!