<br><br>On Tuesday, September 2, 2014, Jorge Schrauwen <<a href="mailto:sjorge%2Bml@blackdot.be">sjorge+ml@blackdot.be</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Attempt 2, because my mail client is dumb.<br>
<br>
Oh another one that came to mind...<br>
Maybe also move omniti-ms to a versioned repository like and rebuild them every release, we now have stuff with build number over th 060 and 080 range! It's not very clean. The again.. that would require reinstall of all those packages every upgrade which may not be what people want.<br>
<br>
</blockquote><div><br></div><div>That has been discussed, though I'm of the opinion that non-core repos (those supplied as add-ons, beyond the release repo) can freely store versions for multiple releases, simply by establishing an incorporate dependency on "entire" at a branch version matching the release on which the package content was built.  This ensures that this package version will only install on one release.</div>
<div><br></div><div>This has been the default in the omniti-ms branch of omnios-build for over a year.  There are still older packages that were built prior to this change, but all of the recently-updated things act this way.  I can also say that Circonus successfully uses this method in our own repos.</div>
<div><br></div>It's also a simple one-line change if anyone wants it in their own forks/copies: <a href="https://github.com/omniti-labs/omnios-build/commit/f9f0f0de">https://github.com/omniti-labs/omnios-build/commit/f9f0f0de</a><div>
<br></div><div>Note, though, that omniti-ms packages are updated on OmniTI's own schedule according to internal priorities, so the complete set may not get rolled for every stable release.<br><div><br></div><div>Eric</div>
</div>