Amqp: Is this project still maintained?

Created on 10 Jun 2020  Â·  7Comments  Â·  Source: streadway/amqp

It seems the activity on this repo, and especially on open issues has progressively waned in 2019 and 2020.
The most conspicuous outstanding issue (IMHO) is #412, plus some other bug reports and open threads which haven't seen maintainer participation in a while.

Of course nobody is demanding anything. We all know that work on OSS done for free is not to be taken for granted and shall be met with users' gratitude and appreciation.
However an update on the state of this project would be very nice indeed.
Thank you.

@michaelklishin @streadway

Most helpful comment

Thanks for the nudge. I don't have so many cycles to maintain changes outside of critical bugs and leave that mostly to Michael.

The project is still maintained, but just at a very slow rate of change :)

All 7 comments

Thanks for the nudge. I don't have so many cycles to maintain changes outside of critical bugs and leave that mostly to Michael.

The project is still maintained, but just at a very slow rate of change :)

I know there are a few issues open, but outside of that is there really any changes that need to be made?

There is this:

This library supports two most recent Go release series, currently 1.10 and 1.11.

Also https://github.com/streadway/amqp/blob/e6b33f460591b0acb2f13b04ef9cf493720ffe17/.travis.yml#L3-L7
is now two versions behind

Despite not importing anything besides the standard library, it would still be nice to have a go.mod so it can be recognized as a module.

I'd be more than happy to PR one or both of those - who should I add as reviewers?

go.mod and similar "housekeeping" changes won't take long to accept.

As for functional changes, this project has a strict "no breaking API changes" policy which greatly limits what kind of changes it can adopt.

I don't feel great about suggesting this but if the community forked this client and adopted a less restrictive release policy, team RabbitMQ would consider switching our tutorials and docs to use the fork instead of this client.

I'll have to fork it to open the PR, and anyone that wants to introduce
breaking changes can always fork the repo and pull changes from this
official version. The RMQ site could link to other, unofficial versions as
they see fit.

This is a great work of FOSS and I'd hate to see it go dormant; these
little housekeeping changes keep it modern, and those of us that are
(ab)using RMQ can certainly bump a Go version from time to time.

On Sat, Aug 15, 2020, 11:11 AM Michael Klishin notifications@github.com
wrote:

go.mod and similar "housekeeping" changes won't take long to accept.

As for functional changes, this project has a strict "no breaking API
changes" policy which greatly limits what kind of changes it can adopt.

I don't feel great about suggesting this but if the community forked this
client and adopted a less restrictive release policy, team RabbitMQ would
consider switching our tutorials and docs to use the fork instead of this
client.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/streadway/amqp/issues/452#issuecomment-674417776, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJEFZQPHHNMHVGSPGJXNP3SA2XTRANCNFSM4N2IE4VA
.

@michaelklishin #394 introduced go.mod and the 1.0.0 tag. This means accepting any API changes can be done by adding a v2 directory and following V2 and Beyond guide.

I can submit a v2 migration to baseline if interested @streadway

Was this page helpful?
0 / 5 - 0 ratings