<br><br><div class="gmail_quote">On Mon, Jun 15, 2009 at 10:24 AM, Aaron Bentley <span dir="ltr"><<a href="mailto:aaron@aaronbentley.com">aaron@aaronbentley.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>No, we consider the dependency to be the other way around-- bzrtools<br>
must pass compatibility testing against the current bzr RC before<br>
bzrtools can be released.<br>
<br>
Forcing bzr to retain compatibility with bzrtools would retard bzr<br>
enhancements, whereas forcing bzrtools to stay up-to-date with bzr is<br>
rarely more than a few minutes' work.<br>
<div class="im"><br>
Aaron<br></div></blockquote><div><br><br>I understand what you are saying. Requiring bzrtools to test against bzrRC is fine. But we still need a mechanism to help people decide when upgrading makes sense for them. That's what I was really trying to say.<br>
</div></div><br>You would be correct to point out that every team using bzr (or considering using bzr) should do acceptance testing before adopting a new version of bzr. But I dare say no one ever adopts just bzr. What they adopt is a toolset including bzr and some plugins. And for better or worse the bzr development community is vastly more qualified to assess the toolset as a whole than anyone else. So winning mindshare will be well served by collecting the plugin compatibility documentation at one place. <br>
<br>As I understand it, this job of making sure everything works together is basically done the hard way by distrinbution packagers, like the ubuntu packagers. But that happens so far upstream, compared to how fast the bzr team fixes bugs. And as you say, the plugins can usually be updated in a few minutes. Distros are slower, for good reason. So there seems to be a need for an intermediate layer, which gets the hard work of the talented bzr core and plugin developers out to users faster than a distro can or should but with at least some minimal promise of stability. And maybe the bzr RM should not have to do this. Maybe it is a new role of Package Integration Manager? <br>
<br>We're not talkign about just any project here. Bazaar is special. We trust it with our data. The time to build confidence is worthy.<br><br>Normally, I keep quiet unless I can volunteer a solution myself. I'm breaking that rule here, because I think this is so important. <br>
<br>Thanks for the open discussion.<br><br>-M<br><br><br>