On Mon, Jun 15, 2009 at 11:50 AM, Aaron Bentley <span dir="ltr"><<a href="mailto:aaron@aaronbentley.com">aaron@aaronbentley.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br> Hash: SHA1<br> <br> Maritza Mendez wrote:<br> </div><div class="im">> I understand what you are saying. Requiring bzrtools to test against<br> > bzrRC is fine. But we still need a mechanism to help people decide when<br> > upgrading makes sense for them. That's what I was really trying to say.<br> <br> </div>Upgrading in what context? If you're using the debs from the PPAs,<br> you'll always have a known-good combination. Same if you're using the<br> Windows .exe installer.<br> </blockquote><div><br>By "upgrading" I mean grabbing the latest stable release in source form to get the fixes I have identified as critical to my team even before they get to the debs. So what you're really saying is I should wait for the debs. I used to do that. Then one time there was a noticeable delay between final and debs, and I realized that I really did not have to wait for debs. That was probably a bad choice by me. <br> <br>Are you saying that the kind of bzr-versus-plugins compatibility I am seeking is guaranteed by the debs? If so, great, thank you and I apologize!<br><br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If you're running from a branch of bzr.dev, then you're living on the<br> bleeding edge, and the process is more manual. But we have frequent<br> releases, so you don't have to live on the edge unless you really want to.<br> <div class="im"></div></blockquote><div class="im"><br>I do keep a local mirror of bzr.dev, but I don't use it unless I suspect a problem is solved in dev that is not already in release. I'm crazy but not that crazy. :)<br> <br> > So winning mindshare<br> > will be well served by collecting the plugin compatibility documentation<br> > at one place.<br> <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I guess we could do this. It would be nicer if plugins could just<br> declare which Bazaar version they supported and have a page that<br> automatically updated based on those values.<br><div class="im"></div></blockquote><div><br>Yeah! <br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im"> > As I understand it, this job of making sure everything works together is<br> > basically done the hard way by distrinbution packagers<br> <br> </div>No, I don't think so. Not everyone tracks the bzr version numbers like<br> bzrtools does, but people are pretty explicit about which bzr versions<br> are supported. Certainly in the case of bzr-svn, you can assume it's<br> *not* compatible with the latest bzr until a version comes out that<br> specifically supports it.<br> <div class="im"></div></blockquote><div><br>That's exactly the kind of information I am seeking. I'm not trying to say one way is right and another way is wrong. All I want is easy access to information which will let an intelligent person make intelligent decisions. That information already exists, but it is not always obvious how to get it.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br> >, like the ubuntu<br> > packagers. But that happens so far upstream, compared to how fast the<br> > bzr team fixes bugs.<br> <br> </div>Do you mean downstream? In common usage, the bzr team is the "upstream".<br> <div class="im"></div></blockquote><div class="im"><br>Sorry. Lost in translation. Yes, I mean later or downstream in workflow. :)<br> <br> > And as you say, the plugins can usually be updated<br> > in a few minutes. Distros are slower, for good reason. So there seems<br> > to be a need for an intermediate layer, which gets the hard work of the<br> > talented bzr core and plugin developers out to users faster than a<br> > distro can or should but with at least some minimal promise of<br> > stability.<br> <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Are the PPAs not that intermediate layer?<br></blockquote><div><br>If you say so. Thanks! Based on one or two bad data points, I thought maybe the PPAs were not held to such a high standard. If they are, then that is exactly what I should be using.<br> <br>Thanks. I learned a lot from this.<br><br>-M <br></div></div><br>