Comments (32)
I think Bunny 0.7 can do that. But master is 0.6.3.pre right now.
from bunny.
Maybe we should first make the tests pass?
They currently fail consistently on my machine.
[~]$ port list rabbitmq-server
rabbitmq-server @2.5.1 net/rabbitmq-server
from bunny.
Same here. I mentioned this in #8.
from bunny.
No doubt about that guys! I wanted to start today, but such a big number of Fs discouraged me ;) But I'll fix it, eventually ... certainly before I'll start with 0.7.
from bunny.
The tests all fail because the initial connection fails. So it's probably only a single line change. But I didn't investigate further, because 0.8 is fine for us.
from bunny.
Pushed a patch to master that makes the 0.9.1 tests pass again. At least they do on my setup with RabbitMQ 2.5.1.
I agree that 0.8 support should be dropped if no-one requires it specifically. RabbitMQ has deprecated the 0.8 spec features that might conceivably have been useful, so keeping support for 0.8 seems pointless.
Bunny runs in 0.8 mode by default at the moment. Would it be worth ripping the 0.8 stuff out for 0.6.3? It wouldn't take too long to do and I'll volunteer for the job if no-one else wants it :)
from bunny.
@celldee: no, 0.8 support absolutely should stay for 0.6.3. For 0.7, it may be reasonable. We need to have a 0.8-enabled release with fixes like reliable timers and so on. Ideally, with most of what @skaes and the Xing team did in bunny-ext.
This is my opinion, anyway.
from bunny.
@celldee OK, if you volunteer, I assigned it to you, I have it on my plate a lot anyway. I agree that we should wait for 0.7. I think we should release 0.6.3 soon with only the most bugs fixed for 0.8. We defnitely should NOT claim we'll support 0.8 in the future (as 0.6.x releases), because a lot of code is about to be rewritten completely and we'd just loose time with 0.8 ... who will need it can take care about it itself. Let's just do the release, tag it and then rip it off.
from bunny.
That's fine. I'll wait for 0.7. In the meantime I'll see if I can get a Jabber client set up.
from bunny.
Speaking of Jabber, we do use it for contributors discussions but everything else is on #rabbitmq on freenode these days, so I also invite you all there (I am antares_). That's how I heard from many amqp and bunny users, for example, @eric.
from bunny.
Sorry to jump in here, but talking about this versioning makes me
wonder if it makes sense to call something 1.0 soon. We have people
using it in production...
from bunny.
Given amount of minor issues and patches scattered across github forks I think bunny is some time away from 1.0. Of course, what goes into 1.0 is a philosophical question every project has own answer for, but this is my impression. Maybe 0.7 can become 1.0 and then AMQP 0.8 support can be dropped in 1.1.
from bunny.
I agree with Michael, there'll be big changes and 1.0 makes the impression
of a stable product. We don't have much documentation for 1.0 either.
Jakub
http://www.flickr.com/photos/jakub-stastny
http://twitter.com/botanicus
On 6 July 2011 21:05, michaelklishin <
[email protected]>wrote:
Given amount of minor issues scattered across github forks I think bunny is
some time away from 1.0. Of course, what goes into 1.0 is a philosophical
question every projects has own answer for, but this is my impression. Maybe
0.7 can become 1.0 and then AMQP 0.8 support can be dropped in 1.1.Reply to this email directly or view it on GitHub:
#10 (comment)
from bunny.
According to SemVer if the next release was 1.0, removing AMQP 0.8 support would be 2.0 (which I think is just fine).
I really think the first question in the semver faq makes sense:
Q: How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
from bunny.
I talked to both @eric and @celldee last night, so far the consensus is that we can name what is currently being referred to as 0.7 to 1.0.
from bunny.
Fine with me.
Jakub
http://www.flickr.com/photos/jakub-stastny
http://twitter.com/botanicus
On 7 July 2011 17:48, michaelklishin <
[email protected]>wrote:
I talked to both @eric and @celldee last night, so far the consensus is
that we can name what is currently being referred to as 0.7 to 1.0.Reply to this email directly or view it on GitHub:
#10 (comment)
from bunny.
Fine with me too.
from bunny.
Chris, would you have time to take a look at this soon? We're about to release 1.0 (see the mailing list), so this will fairly important.
from bunny.
Sure. I was thinking that as soon as the 1.0 code base is set, then I could strip out the 0.8 stuff from that. Does that work for everyone?
from bunny.
@celldee: sorry, does this mean that 1.0 will include AMQP 0.8 support? I think that's fine, in fact, preferable IMO but we need to release 1.0 fairly soon then.
from bunny.
Sync amq-client part is still weeks away and I think it is a good idea to move bunny 1.1 to it.
from bunny.
@michaelklishin My understanding was that the next release would retain the 0.8 stuff and then it would be removed after that. Correct me if I'm mistaken, but I thought that the next release was going to be 0.7 but has been renumbered to 1.0. @botanicus wants to release 1.0 on Monday I believe and that's fine by me. If anyone was expecting 1.0 to have the 0.8 stuff removed, I could do it on Sunday, but as I said, I thought that we had agreed to wait.
from bunny.
I forgot about v0.6.3. This is at 0.6.3.rc2 now right? So is there going to be a 0.6.3 to tidy up 0.8 support?
from bunny.
if we are going to release 1.0 on Monday, 0.6.3 probably doesn't matter :) and for 1.1, AMQP 0.8 support will be dropped.
from bunny.
I was just wondering whether there was an intention to have 0.6.3+ continuing 0.8 support with appropriate fixes, and then have the 1.0+ series drop 0.8 support.
from bunny.
I must say, I find the intended numbering scheme a bit misleading. 1.0 would
be just 0.6 plus a few bug fixes.
OTH, Dropping 0.8 protocol support is a major change, since it will enforce
a protocol change onto every user of the gem, with unknown consequences.
Right now, bunny is a critical piece of our core infrastructure at XING. We
would certainly need some serious testing as soon as the protocol switch is
enforced.
I would prefer to use 0.7 for the next release, and 1.0 for the version
which drops 0.8 protocol support.
But in the end, it's just a matter of tase and I could live with either
decision.
On Fri, Jul 15, 2011 at 11:36 PM, celldee <
[email protected]>wrote:
I was just wondering whether there was an intention to have 0.6.3+
continuing 0.8 support with appropriate fixes, and then have the 1.0+ series
drop 0.8 support.Reply to this email directly or view it on GitHub:
#10 (comment)
from bunny.
I'm all for 0.7. So can we agree on it?
Yes, the work on removing 0.8 can start (in a separate branch).
from bunny.
Sorry if my suggestion lead to confusion. My thoughts were just that if people (like xing and papertrail) are using it in production, it pretty much is something I would consider 1.0.
Looking at semver.org, it looks like we would want to bump it to v2.0 when we removed the 0.8 support:
- Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes.
I understand all of these version bumps may be too much to take on right now, so I'm fine with calling the next release 0.7 and figuring out what to do after that.
from bunny.
I'm happy to go with 0.7 for the next release and I'll rip out the 0.8 stuff in a separate branch.
from bunny.
I have created a branch called 'remove_0.8'. This contains the 0.7 code with the AMQP 0.8 specific stuff removed. I ran the tests and they passed. Please take a look and let me know if everything is OK or not.
from bunny.
Thanks Chris, looks good to me. You don't have to be afraid to commit to
master now as 0.7 is out.
Jakub
http://www.flickr.com/photos/jakub-stastny
http://twitter.com/botanicus
On 19 July 2011 01:59, celldee <
[email protected]>wrote:
I have created a branch called 'remove_0.8'. This contains the 0.7 code
with the AMQP 0.8 specific stuff removed. I ran the tests and they passed.
Please take a look and let me know if everything is OK or not.Reply to this email directly or view it on GitHub:
#10 (comment)
from bunny.
I just pushed 0.7.x-stable branch. Will make master 0.8.0.pre1 next.
from bunny.
Related Issues (20)
- Gem includes test certificates HOT 3
- Cannot subscribe to existing queue with no configure permission HOT 2
- Redeliver publisher confirms acks again and again from 0 till current tag HOT 4
- Binding a queue to same exchange twice but using different routing keys not working as expected HOT 1
- any plans to support the new rabbitMQ stream plugin with RabbitMQ 3.9? HOT 4
- Queue subscribe: Calling thread is no longer blocked after connection failure HOT 2
- TLS 1.3 support HOT 2
- QueueDeclare / Timeout issue
- Bunny does not recover from Rabbitmq Broker restart but reconnects on manual restart of service
- Confusion of parameters
- NameError: uninitialized constant OpenSSL::SSL::TLS1_3_VERSION (bunny-2.20.0, ruby 2.6) HOT 4
- Bunny::Channel#quorum_queue does not result in a QQ declaration
- Conditionally alias constants for TLSv1.3 to support older OpenSSL releases
- OpenSSL error is causing unrecoverable issue HOT 1
- Bunny::Channel#default_exchange returns a new object each time
- Missing client notification when recovery fails (after specified recovery attempts) HOT 1
- Reader Loop: undefined method handle_frameset for nil:NilClass
- Heartbeat sender uses Time.now which is unreliable HOT 6
- Channel callback from delivery acknowledgement timeout.
- `basic_cancel` makes other channels wait
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bunny.