hex.pm release

[ruslandoga]

👋

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]

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]

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]

@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]

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.