Stable releases of Bazaar?

[David Ingamells]

Martin Pool wrote:
> On Mon, Jul 28, 2008 at 6:06 AM, Colin D Bennett <colin at gibibit.com> wrote:
>   
>> On Fri, 25 Jul 2008 09:41:43 +0200
>> David Ingamells <david.ingamells at mapscape.eu> wrote:
>>
>>     
>>> Jonathan Lange wrote:
>>>       
>>>> On Fri, Jul 25, 2008 at 1:16 PM, Martin Pool <mbp at canonical.com>
>>>> wrote:
>>>>         
>>>>> For people to be happily using stacking with launchpad we need
>>>>> them to install 1.6.
>>>>>
>>>>>           
>>>> Or perhaps 1.7. The 1.6 release changes a lot of things and is
>>>> therefore likely to have more than its share of bugs.
>>>>
>>>>
>>>>         
>>> Has the Bazaar team considered identifying certain releases as stable
>>> releases which will enjoy ongoing support with bug fixes being
>>> applied?
>>>       
>> I just have to pipe in and say that one of the things I am very
>> impressed with about Bazaar is the rock solid stability of every
>> release--and even bzr.dev!
>>
>> So I fear that if bzr were to begin using a "stable" and "unstable"
>> concept of versions, we might get sloppier about the code going into
>> the mainline...
>>     
>
> I don't think it would make us any less strict about what's in
> mainline, because having it be unstable would just be such a pain for
> people doing ongoing work.  However making a different stable release
> branch does take work; unless someone new is motivated to do it (which
> would be great) it would take away from forward development.  Add to
> this that you'll never please everyone with which things you choose to
> take back or not.
>
> I think for David probably the practical thing is to to wait for a
> while until 1.6 has had time to settle and then install either 1.6,
> 1.6.1 or 1.7 depending on how things pan out.
>
>   
I thought 'rock solid' too until:
1) I moved our repositories over to bzr+ssh:// because of the horrible 
performance with file:// to an NFS filesystem (problem is with NFS, not 
bzr). Everyone had been saying such good things about the smart server 
that I felt confident to make this move.
2) I upgraded a couple of repositories to pack-0.92. Everyone has been 
saying that this format is much better all-round so I felt confident 
making the upgrade.

Suddenly bzr v 1.5 was less that 'rock solid'. (i.e. someone has got 
sloppy :-\ )

I don't know if the problems I've encountered have been solved in v 1.6, 
but I do know that v 1.6beta2 has terrible performance with dirstate-tags.

My advice is to make sure that your regression tests cover all 
combinations of usage (not an easy thing to achieve) since it is this 
above all else that keeps developers from getting sloppy. Until you are 
sure that your tests are 100% coverage it will give users confidence if 
one particular release will continue to be supported and kept stable so 
that they can choose when to move forward to a newer release.

If the developer who caused the bug were required to fix it then there 
would be MORE motivation to get it right first time if he knew that he 
might later have to fix the problem in multiple releases.