<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&#39;s worth noting, however, that we&#39;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&#39;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&#39;t know-- it wasn&#39;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">&lt;<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;m not sure how you would normally deal with a source RPM in this respect, but anyway the src RPM that you&#39;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>
&gt; 1) Is there something special we should be doing in our build environment to fix this?<br>
<br>
</div>Don&#39;t know - our rpm generation works fine, so maybe try to crib some ideas from there?<br>
<div class="im"><br>
&gt; 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&#39;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>