<div>On 8/9/07, Matthew D. Fuller <<a href="mailto:fullermd@over-yonder.net">fullermd@over-yonder.net</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Fri, Aug 10, 2007 at 02:28:03PM +1000 I heard the voice of Robert Collins, and lo! it spake thus: > > they won't be affected by a change to 0.90 - but the folk that react > emotively will be. Well, yeah.  My point is that *I* react emotively to it, and it's a negative emote.  The first version of bzr I used was 0.6, and I'm glad of that, as I once had occasion to look back and try and find out when 0.5 was released... "Wow, Solaris 7 is out already?  Seems like I just installed 2.6..."</blockquote><div> I feel like you guys are underestimating your users here.  We are also developers.  We understand that release minors are usually just incremented and are not going to read too much into them.  I think in terms of communicating to your users you need a major (especially that all important 1.0) that represents major incompatible changes.  I think the disconnect is that there is also a need to know when there is a release that you the dev team would really like people to use and upgrade to, which is usually what the minor is for, but in your development cycle is more based on the time.  (Upgrading your SCM every month is a bit heavy from most people).  Maybe these two concerns should be split: Major.minor.patch for blessed releases.  (the minor goes up when you want people to upgrade, patch for critical bugfixes) and a <major>.<minor>.dev-<date> for the monthly releases, with minor being 1 + the blessed release. BTW, once really start the run for 1.0 release, I think the better P.R. move is to go with the release candidates (1.0.0rc1).  That's a real strong signal to the community that you really want their help in nailing out the last bugs and issues. </div></div>