search

zeromq / zmqpp

0mq 'highlevel' C++ bindings
http://zeromq.github.io/zmqpp
Mozilla Public License 2.0
439 stars 195 forks source link

Latest release? #118

Closed chefhoobajoob closed 9 years ago

chefhoobajoob commented 9 years ago

This isn't really an issue, but is 3.2.0 from late 2013 the latest stable release? Changes.md suggests that there is a 4.1.1, but it doesn't seem to show up on the list of releases here: https://github.com/zeromq/zmqpp/releases.

Is the recent activity working towards an upcoming 4.1.1 release, or am I just not looking in the right place?

xaqq commented 9 years ago

Hello,

Yes we haven't been formally releasing since 3.2.0. However the develop branch is quite stable and I believe you can safely rely on it (I do).

chefhoobajoob commented 9 years ago

we haven't been formally releasing since 3.2.0.

...does this mean that there won't be any more entries in the 'releases' list from now on? So, there's a commitment that whatever's at the tip of the develop branch is 'production ready' and compatible with earlier releases? Or, is there some other process in place? Also, for version tracking, what do I refer to the tip as, if it's not tagged with a version?

hintjens commented 9 years ago

FWIW, tagging the releases works quite well in GitHub, and I'm using this for CZMQ now, including for downloads.

On Thu, Jun 11, 2015 at 7:36 PM, jameswm notifications@github.com wrote:

we haven't been formally releasing since 3.2.0.

...does this mean that there won't be any more entries in the 'releases' list from now on? So, there's a commitment that whatever's at the tip of the develop branch is 'production ready' and compatible with earlier releases? Or, is there some other process in place?

— Reply to this email directly or view it on GitHub https://github.com/zeromq/zmqpp/issues/118#issuecomment-111217601.

chefhoobajoob commented 9 years ago

Yeah, that is fairly easy for consumers to deal with - some kind of identifying number for a meaningful increment in the code. I typically import the binary builds into our build automation system with a version tag, and it's kind of hard to keep that going and meaningful to developers when there isn't something to correlate to here on github. Like, if I pull the current development branch tip here, should I call it 4.1.1? I'm currently running against 3.2.0.

hintjens commented 9 years ago

How we do it in libzmq and CZMQ and other projects:

So e.g. CZMQ latest stable is 3.0.2 and git master builds 3.0.3 (unreleased).

On Thu, Jun 11, 2015 at 7:52 PM, jameswm notifications@github.com wrote:

Yeah, that is fairly easy for consumers to deal with - some kind of identifying number for a meaningful increment in the code. I typically import the binary builds into our build automation system with a version tag, and it's kind of hard to keep that going and meaningful to developers when there isn't something to correlate to here on github. Like, if I pull the current development branch tip here, should I call it 4.1.1? I'm currently running against 3.2.0.

— Reply to this email directly or view it on GitHub https://github.com/zeromq/zmqpp/issues/118#issuecomment-111222069.

xaqq commented 9 years ago

...does this mean that there won't be any more entries in the 'releases' list from now on?

No. We didn't decide to stop, it's just that no one really went ahead and draft a new release. If anything it means we should get to work and do it, rather sooner than later.

So, there's a commitment that whatever's at the tip of the develop branch is 'production ready' and compatible with earlier releases?

Not really either. There's been time where some thing were broken in develop's HEAD.

Like, if I pull the current development branch tip here, should I call it 4.1.1?

Yes go ahead and do that. I'll probably draft a release in the next few day and I'll tag it 4.1.2.

chefhoobajoob commented 9 years ago

Ok. If you put together release notes or anything, one thing I've found in moving from 3.2.0 is that for binary blob frames where I used to append to messages using zmqpp::message::add( blob, blobSize), I had to change these calls to use add_raw( blob, blobSize ) instead.

This difference is significant, because leaving the calls unchanged compiles successfully, but at runtime it has the effect of adding two parts instead of one to the message because the compiler's resolving it to the newly-added variadic add() method, treating each argument as a new part.

xaqq commented 9 years ago

We have 4.1.2 now. Thank you for this comment, added that to release notes.