Four! was Re: Two major releases per year instead of three

Mads Kiilerich mads at kiilerich.com
Thu Aug 4 23:13:39 UTC 2011


Lester Caine wrote, On 08/05/2011 12:32 AM:
> Mads Kiilerich wrote:
>> The lack of stable API (as used by extensions and TortoiseHg) do however
>> mean that it isn't a good idea to push new Mercurial releases
>> (especially not major releases) as updates to released stable OS
>> releases. It might thus be an advantage that the major release has
>> stabilized even more in minor releases and extensions have caught up.
>
> This is certainly what caught many of us out? 1.9 was pushed out as an 
> update in the SUSE repos without the correct supporting updates.

It is quite common - and easy - to install Mercurial extensions 
manually, so I doubt any amount of supporting updates would have made 
the update to Mercurial 1.9 "safe" from an OS stability point of view.

> Had I actually spotted it buried in a wodge of security updates I 
> might not have loaded it, but without the correct 'protection' to 
> ensure that a previously working build required the extra packages 
> there is little guarantee that things will remain working? While the 
> work of who ever pushed the update to the repo is welcome, it does 
> need to be done with a little more understanding of what will happen?

Pushed the update to which repo?

Pushed to Mercurials repo? The Mercurial repo has a very clear policy 
that internal APIs can be changed at any time - even though it shouldn't 
happen in minor releases. The API changes for 1.9 were thus ok and 
followed the rules - and 2.0 might have a similar amount of API changes.

Pushed to the SUSE update repo? Yes, pushing an update to Mercurial 1.9 
as a bugfix in a stable release was thus perhaps not a good idea.

/Mads



More information about the Mercurial mailing list