<div dir="ltr">Thank you for the response. Looking in the Makefile, I see this:<div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>VERSION:=0.0.0</div></div></blockquote><div>
<div><br></div><div>And I found this in the README in the rabbitmq-public-umbrella, which seems to confirm it:</div><div><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>
<div><div>By default, PACKAGE_VERSION takes its value from VERSION. VERSION is</div></div></div><div><div><div>a global (not per-package) variable intended to be set when invoking</div></div>
</div><div><div><div>make in order to specify the version number for the release. So, if</div></div></div><div><div><div><a href="http://package.mk" target="_blank">package.mk</a> does nothing to change the default behaviour, the version</div>
</div></div><div><div><div>number of a package will be the release-wide version number from</div></div></div><div><div><div>VERSION. By default, VERSION has the value 0.0.0.</div></div>
</div></blockquote><div><div><br></div><div>It's worth noting, however, that we're not the only ones who apparently have been caught by this. If you look at the most recent published RPMs from the Fedora Project and <a href="http://altlinux.org" target="_blank">altlinux.org</a> (albeit the most current are still old), you'll see that their published RPMs for RabbitMQ also have 0.0.0 plugins:</div>
<div><ul><li><a href="http://fedora.mirror.nexicom.net/linux/development/rawhide/x86_64/os/Packages/r/rabbitmq-server-3.0.4-1.fc20.noarch.rpm" target="_blank">http://fedora.mirror.nexicom.net/linux/development/rawhide/x86_64/os/Packages/r/rabbitmq-server-3.0.4-1.fc20.noarch.rpm</a><br>
</li><li><a href="ftp://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/files/noarch/RPMS/rabbitmq-server-2.8.7-alt2.noarch.rpm" target="_blank">ftp://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/files/noarch/RPMS/rabbitmq-server-2.8.7-alt2.noarch.rpm</a><br>
</li></ul></div><div>As for why we repackage, I don't know-- it wasn't my decision. I guess maybe we are control freaks? ;-) </div>
<div><br></div><div>Thanks,</div><div>Chris</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 31, 2013 at 8:35 AM, Tim Watson <span dir="ltr"><<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure how you would normally deal with a source RPM in this respect, but anyway the src RPM that you've downloaded only contains the sources and these are given a release number by the build system. Take a look in the various shell scripts and makes files in the rabbitmq-public-umbrella for details.<br>
<br>
Is there are a reason why you need to package from source yourselves?<br>
<div class="im"><br>
On 30 May 2013, at 21:01, Chris wrote:<br>
<br>
> 1) Is there something special we should be doing in our build environment to fix this?<br>
<br>
</div>Don't know - our rpm generation works fine, so maybe try to crib some ideas from there?<br>
<div class="im"><br>
> 2) Are these incorrectly versioned filenames harmful?<br>
<br>
</div>Probably not. RabbitMQ brokers will refuse to cluster if their major versions differ, however for plugins there may be no adverse affects at all, but don't take that as gospel. Also it could be confusing for folks trying to offer on-list support if your rabbitmqctl output shows plugin version numbers of 0.0.0.<br>
<br>
Cheers,<br>
Tim<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br></div>