<br><br><div class="gmail_quote">On 5 January 2013 08:48, Jack O'Quin <span dir="ltr"><<a href="mailto:jack.oquin@gmail.com" target="_blank">jack.oquin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="gmail_quote"><div class="im">On Fri, Jan 4, 2013 at 3:00 PM, Tully Foote <span dir="ltr"><<a href="mailto:tfoote@willowgarage.com" target="_blank">tfoote@willowgarage.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">My best estimate was that rolling over the version numbers to even values would cost us a full week of work for the core team and would require every single maintainer to respond quickly to the request to rerelease.  And availability of all maintainers any specific week is not likely.  Because of this large overhead I didn't ask everyone to comply with that policy.  You'll note I've updated the Version Policy wiki page to reflect that too.  </div>
</blockquote></div></div></blockquote><div><br></div><div>+1. </div><div><br></div><div>Another comment, that policy indirectly had core ros stacks synchronising with the 'ros release' number, which was always odd. roscpp for instance, has only had relatively minor changes over something like 0.6 -> 2.0, but focusing solely on the version number - that would seem to tell another story.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><br></div><div>I think what this points out is that we need to make sure we develop a way to know what versions of packages are available in the debian repository.  And we should make the Changelogs much more visible.  There was a discussion long ago about moving the Changelogs from the wiki back into the source. I think it's time to revive that discussion.  Especially now that we have tools like bloom which could inject that information into the debian packages now.  </div>



<div><br></div><div>Also we should update REP 9 to not reference the even odd scheme, but be more explicit about when and where things should be compatible.   </div></div></blockquote></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>And the last thing we should do is find a way to integrate some of the ABI checking tools into the prereleases to help maintainers know when things slip through the cracks. </div>
</div></blockquote></div></div></blockquote><div><br></div><div>I think this would be a good idea to slip in with the concept of '1.0 is stable'. Since bloom assumes a major.minor.patch number, you could bring in the abi tools to generate warnings/errors for any abi breakages in versions over 1.0.0 and allow freedom to break abi while it is < 1.0.0. </div>
<div><br></div><div>Right now the concept of being 'stable' has no responsibility attached to it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
</div></blockquote><div><br></div></div><div>+1 to all of that</div></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- </font></span></blockquote></div>