New release?

[thomaslee]

Howdy -- I maintain the hiredis Debian packages. We've run into an interesting situation because redis vendors/bundles hiredis. The vendored library runs afoul of Debian policy rules, because we'd rather have redis use the system's shared hiredis to avoid unnecessary bloat. However, in trying to modify redis to use the shared/system hiredis (which is a very lightly modified 0.13.3) we've discovered that the bundled version of hiredis is API-incompatible with 0.13.3. See Debian tickets 907258 and 907259 for details of the specific issue we're trying to resolve.

We can work around this on the Debian side by packaging up Git master as of some arbitrary SHA, but would prefer not to: as you can probably imagine that's both a headache for users who might be building third-party/"external" software against the hiredis Debian packages or package maintainers who might be (reasonably!) trying to port software based on 0.13.3 to Debian.

Before I go raining on anyone's parade on the Debian side, is there any possibility we could twist your arm for the 1.0.0 release, or at least another 0.x release with an API compatible with the version bundled with redis? If something specific is holding up a release & it's just a question of manpower, let me know how I can help.

[mnunberg]

Looking at the bugs themselves.. Do you have sds as its own DSO? From what I can tell (new here) the 'releases' are nothing more than a tag. We can certainly give a name for something, so that people can refer back to it.

[lamby]

'releases' are nothing more than a tag

That would be totally fine.

[thomaslee]

Do you have sds as its own DSO?

Nah think it all ends up in libhiredis.so. We don't do anything too strange relative to the bog-standard Makefile. You can see the Debian-specific patches (against 0.13.3) over here:

https://github.com/thomaslee/hiredis-debian/tree/master/debian/patches

From what I can tell (new here) the 'releases' are nothing more than a tag. We can certainly give a name for something, so that people can refer back to it.

Yep, think that's all I'm asking for -- albeit ideally with the usual semver & ABI compatibility concerns taken into account in the version numbers, SONAMEs, etc.

It might seem like a small thing, but in addition from the packaging concerns it also helps anyone trying to port hiredis (or software that depends on hiredis) to different platforms.

[mnunberg]

Does current master seem to be working for you?

[thomaslee]

Glad you asked: for starters, seems like there's some overlap between hiredis/read.c and redis/src/util.c (string2ll) which causes linker errors. Probably a few more to come at a glance. It looks like redis itself is using something of a frankenstein of whatever landed in redis/redis@6712bce and a backport of our kfreebsd patch in redis/redis@fb6ebaa.

I'll see if I can untangle things enough to get the redis tests passing later tonight/tomorrow.

[thomaslee]

On a whim I made string2ll static & it resolved all the build errors, so I was able to build redis using hiredis master + a 1 line change (i.e. int string2ll -> static int string2ll in hiredis' read.c). All tests passing + benchmarks running fine. I can PR that one-liner if you like, but seems like a pretty trivial change if it's easy for you guys to sneak in & string2ll is not intended to be part of the public API 😃

[thomaslee]

(And if it's not obvious HIREDIS_{MAJOR,MINOR,PATCH,SONAME} in hiredis.h will all need a bump when we're ready for the new release too)

[mnunberg]

Go ahead and make that PR. Let's give it a day to see if anyone else has any suggestions. @michael-grunder ?

[thomaslee]

Done -- thanks for the speedy follow-up! I can also PR the hiredis.h changes too if that's useful, just need to know what you want to call the next version.

[michael-grunder]

No objections on my end. I probably should have made that static to begin with 😄

If it's sufficient I think another 0.x release is the way to go, as we'd probably want to merge #597 if we bump a major version.

[thomaslee]

Awesome. I can PR the changes to hiredis.h for a 0.14.0 release (or whatever you folks feel is appropriate) if that's helpful. And again, thanks so much for moving on this stuff so quickly!

[mnunberg]

@thomaslee go ahead and make the PR changes. Nobody's objected so far.

[thomaslee]

Sure, done -- #612

Perhaps you folks are already aware of it, but since I may not be involved in future releases just a reminder: if we break ABI compatibility, the SONAME should change. Highly recommend trying to maintain ABI compatibility between major releases from 1.0 onwards -- another one of those "makes things easier for package maintainers and end users" things. 😃

Prior to 1.x, simply bumping the minor version + SONAME (like I did in #612) with any ABI-breaking changes should suffice.

More discussion & links to additional info over in #327.

Anyway, let me know when we've got a tag for 0.14.0 and I'll close this out & get the Debian packages updated. Again, thanks so much!

[mnunberg]

and.... it's done

[thomaslee]

Cheers!

[michael-grunder]

Hey @mnunberg, not a huge deal but I think we might want to update the changelog to include 0.14.0.

My understanding is that we have a lot more latitude here since we're still in pre 1.0 territory. I'm happy to put together the list this evening.

[mnunberg]

Sure!

…

On Sep 25, 2018, at 7:49 PM, Michael Grunder ***@***.***> wrote: Hey @mnunberg <https://github.com/mnunberg>, not a huge deal but I think we might want to update the changelog to include 0.14.0. My understanding is that we have a lot more latitude here since we're still in pre 1.0 territory. I'm happy to put together the list this evening. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#609 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAanUVtNXJQWs2IeW2-x2ihnrlMbT56hks5uesEggaJpZM4W3cUI>.