Recent update to bzr.dev is a blocker

[Vincent Ladeuil]

>>>>> "Russle" == Russel Winder <russel.winder at concertant.com> writes:

    Russle> Aaron,
    >> > The bzrtools I have is a branch of http://bazaar.launchpad.net/%
    >> > 7Eabentley/bzrtools/bzrtools.dev  According to
    >> > http://bazaar-vcs.org/BzrTools this is the most up to date version of
    >> > BzrTools that it is possible to get.
    >> 
    >> My apologies.  Usually, I update the version number before the RC goes
    >> out.  I have pushed up a new version.

    Russle> OK, thanks.  I guess now I just have to hassle Jelmer to `fix' bzr-svn
    Russle> 0.4 branch which claims it can only work with bzr 1.6:

    >>> grep COMPAT __init__.py
    Russle> COMPATIBLE_BZR_VERSIONS = [(1, 6)]
    >>> 

    Russle> Change the 6 to an 8 and it all works.  Well hopefully it does, I guess
    Russle> there are no guarantees.

    Russle> I think we have here another instance of left hand
    Russle> and right hand failure to communicate.

I don't think so, see below.

    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 :)

    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.

    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.

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.

    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.

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.

    Russle> Well hopefully it does, I guess there are no
    Russle> guarantees.

Contact the plugin authors, they are probably aware of the issue
:-)

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,

     Vincent