Closed michaelklishin closed 7 years ago
The only reason is my laziness to migrate and learn what changed. (I am unnable to fix the 3.6.x version and I am getting the 3.7.x instead which changed a bit.) Is there some plugin versioning guideline, please?
What do you mean by "unable to fix the 3.6.x version"?
I can look into adapting your build system for what's used by all RabbitMQ 3.6.x plugins our team maintains.
You can version your plugin however you please. Since there are two RabbitMQ branches under active development, it makes sense to have two branches in a plugin.
So if I want to build against 3.6.9, I should do it in a "stable" branch of my plugin, right?
@gotthardp that's what we do e.g. for rabbitmq-autocluster. All plugins maintained by our team have a stable
branch by definition. But it's not really about what branch this repo uses. What RabbitMQ branch you build against matters a lot more ;)
But if I recall correctly the branch I am building against is auto-determined from the plug-in branch. Or is there a way to specify in the Makefile what to build against?
@gotthardp you clone the umbrella, gmake up BRANCH=stable
if you want stable, then clone your plugin under deps
and switch it to any branch you want.
Anyhow, I'm ready to convert this plugin and its dependencies to the current umbrella if you are interested. Otherwise I can locally produce and share a new binary release you can stick into GitHub releases.
v0.2.0 was released (thanks!), so I guess we can close this
@gotthardp this plugin hasn't seen a release in over 1 year. Perhaps it's time to produce a 3.6.9-based release (and perhaps mark it as a GA one, not a preview)?
Are there any reasons to not do this soon?