Recent update to bzr.dev is a blocker

[Russel Winder]

On Wed, 2008-09-10 at 20:48 +0200, Vincent Ladeuil wrote:
> >>>>> "Russle" == Russel Winder <russel.winder at concertant.com> writes:

What a bizarre idea -- change the spelling of a person's name ;-)

[ . . . ]

>     Russle> Some plugins make statements about which versions of
>     Russle> Bazaar they work with but there is no coordination of
>     Russle> version number updating happening.
> 
> Indeed there is. bzr deprecate some methods from time to time or
> the plugin may use some private part of bzr (and in that case,
> get what it deserves: no deprecation and a failure :)

I agree there is some infrastructure for handling relatively graceful
evolution of deprecation, the current situation is though about version
numbers, for which there seems no equivalent lightweight infrastructure.

>     Russle> OK so working with mainline of bzr and plugins is on
>     Russle> the bleeding edge, so trouble can be expected.
> 
> Yes, from the plugins.

I agree that the problem lies in the plugins not in bzr.dev per se, but
bzr.dev isn't generating warnings for people to complain about when
there is a version mismatch.

bzr-svn seems a case in point.  The 0.4 branch appears to depend on bzr
1.6.  I have been using it with bzr.dev numbering itself 1.7 for a while
and yet there has been no hint of there being a problem.  I suspect
there should have been warnings issued (as there are for deprecation
violations) so that users would become aware of the impending disaster
when bzr.dev moves to 1.8.

>     Russle> However, every time there is a version number change
>     Russle> there seem to be cracks.
> 
> No. The plugin authors are free to not check bzr version. If they
> do, that's for a reason: they don't want to risk their plugin to
> be misused in contexts they didn't test.

I don't disagree that effectively the responsibility lies in the plugin,
however bzr is providing infrastructure in which plugin do what ever
they are allowed to.  Version number mismatch is being treated as either
working or failing, there is no graceful degradation mode.

> That works both ways: 
> 
> - old plugin don't work with new bzr
> - new plugin don't work with old bzr
> 
> Being on the bleeding edge is one use case. Some people use bzr
> for a long time (without upgrading even to stable releases) and
> suddenly they discover a plugin and want to try it.
> 
> The version check protect them.

I wasn't arguing that plugins shouldn't make version checks, my
"complaint" is that there is no indication of a part-broken
configuration.  Apologies to Jelmer (who is doing a great job with
bzr-svn), but the 0.4 branch was broken in that it was checking for bzr
1.6 but there was no warning that actually bzr 1.7 was being used.  bzr
is at fault for not raising a flag that it was allowing a part broken
situation to proceed.

>     Russle> The problem is that bzr.dev is supposed to have a
>     Russle> number change every month so this should be a
>     Russle> standard thing that shouldn't cause problems.
> 
> Automating API changes is a vast problem. We barely scratch the
> surfaces by issuing deprecation warning while ensuring backward
> compatibility.

But at least warnings allow a situation to be known about.  My
irritation of the moment is that there was no indication that there was
a problem, a broken bzr/bzr-svn configuration was allowed to work
silently, then it just broke.

> The commitment made by bzr regarding the API is already pretty
> strong (even if how we do it is still discussed ;) and many
> plugins never need to be updated and when they need it:
> 
>     Russle> grep COMPAT __init__.py
>     Russle> COMPATIBLE_BZR_VERSIONS = [(1, 6)]
>     Russle> 
> 
>     Russle> Change the 6 to an 8 and it all works.
> 
> That's often all that is needed.

It is working at the moment, but this is just a "dirty hack" on my part
based on guesswork and prayer.

>     Russle> Well hopefully it does, I guess there are no
>     Russle> guarantees.
> 
> Contact the plugin authors, they are probably aware of the issue
> :-)

I am about to create a bug report.  However this is not entirely
Jelmer's fault.  OK bzr-svn checks for version 1.6 but that is fine
since 1.6 is the latest released version.  The question is how does
Bazaar as a system deal with the fact that there are three and not two
versions of bzr in play at any one time.

> And they will give you the guarantee you're searching for (err
> wait what says the GPL about that :).
> 
> And we are talking about bzrtools here, the mere fact that not a
> single update has been needed for the last bzr version is a
> pretty good example.
> 
> And since this is bzrtools you can try:
> 
>    bzr selftest -s bp.bzrtools -v
> 
> and see how many tests are failing.
> 
>     Russle> Sorry to be grumpy on this but it just strikes me
>     Russle> that this should have been sorted out long ago.
> 
> I for one don't expect it to be solved even in the 20 coming
> years :D
> 
> Don't get me wrong, I am a plugin author and I chose to check the
> bzr version trying to run my plugin. It saved me more than a few
> times.
> 
> Hope this clarify the issue,

Indeed, but the fact remains that bzr.dev is two versions and not one
away from the released version and this is at the root of the problem
since the code reifies the fact that bzr.dev is only one version away
from the released version.

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080911/135a54a1/attachment.pgp