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.

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

hex.pm release #36

Open
ruslandoga opened this issue Nov 7, 2021 · 4 comments
Open

hex.pm release #36

ruslandoga opened this issue Nov 7, 2021 · 4 comments

Comments

@ruslandoga
Copy link

ruslandoga commented Nov 7, 2021

👋

I wonder if it would be possible to publish erlfdb on hex.pm?

Or maybe it's published already but I'm missing it ...

@kocolosk
Copy link
Member

kocolosk commented Nov 7, 2021

You're not missing it! I definitely think this would be a good idea.

One aspect we wanted to have a discussion about was how these packages would interact with ASF standards regarding software releases, since this codebase started out as a component of Apache CouchDB. For example, do we need to hold a vote on the mailing list every time we declare a new version of erlfdb ready for external consumption as a hex.pm package? I started a discussion about this here - the TL;DR is that we probably should treat those as official software releases but we can try to minimize the overhead for the community to approve them.

Does that make sense?

@kocolosk
Copy link
Member

kocolosk commented Nov 9, 2021

I also think this is an opportunity to take a closer look at the release versioning scheme we use for this library. Currently there's no easy way to determine the minimum erlfdb version necessary to use features associated with a given FoundationDB API version. The FDB API version is typically incremented for every minor FDB release, e.g. FDB 6.3.x releases are all at API version 630.

One thought I had was to adopt the FDB API version as the major release number for erlfdb releases; e.g. we can release a 630.0.0 when we've confirmed that we're supporting the features introduced in API version 630. That still gives us two degrees of freedom for introducing features and fixes, while providing a more meaningful mapping to FDB versions.

It's worth noting that older erlfdb versions can be used with newer FDB installations following some of the recent work that has been merged -- they just can't invoke the newer API operations. So the statement is "if you want your app to use features in API version X, make sure the erlfdb app is at least X.0.0"

@nickva curious to get your thoughts on this one.

@nickva
Copy link
Contributor

nickva commented Nov 10, 2021

@kocolosk that sounds like a good idea, I am on-board. It would be a nice ergonomic improvement.

When building against higher FDB version one place a user could be surprised is if the returned data from the API changes like with the get_addresses_for_key in 630. But having an obvious version number in the release tag would be an indicator for the users to scrutinize API differences if they are using the library with a higher FDB version.

For backwards compatibility, building against 620, we could just declare some minimum version we'd be willing to support, as long as want to sprinkle a few #if ... macros here and there.

@kocolosk
Copy link
Member

Regarding higher versions, we'd also get the additional property that e.g. 630.X.Y releases would default to having api_version 630 in the application environment configuration, so a user who did build against a newer C library would also need to override the default environment API version in order to see the modified behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants