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