Release testing and the relationship between 'bzr selftest' and plugins

[Alexander Belchenko]

Vincent Ladeuil пишет:
>>>>>> Jelmer Vernooij <jelmer at samba.org> writes:
> 
> <snip/>
> 
>     > The API versioning infrastructure doesn't work
>     > ----------------------------------------------
> 
> Sad but true.

I think the problem is in the fact that bzrlib is too big and has very 
big public API: a lot of classes and methods. Multiply it to the 
possible changes in algorithms or main ideas behind those classes. E.g. 
whether some code should use Inventory or it shouldn't.

The main source of frustration is in the fact that changes in ideas 
behind classes are backward incompatible, so that breaks plugins.

Changes in API itself are lesser evil for me, but it's often annoying, 
e.g. when some public method gets new non-optional argument.

I'd like to share what I'm trying to do in qbzr and bzr-explorer (as the 
prominent example of client application has been built on top of qbzr) 
to achieve better backward compatibility between different combination 
of their versions.  I'm not quite sure how much would it help there.

 From my non-bzr experience, using version numbers is not very good when 
you have too much moving parts. So, much better if you have a set of 
flags which are indicated features supported or provided in the current 
version. If client needs to use some specific feature of the base code 
then it should check features set, and therefore client can adjust its 
behavior, and even support old codepath and new (without/with a feature).

So in qbzr I made special dictionary FEATURES which could provide to 
clients information about availability of some new features (comparing 
to some arbitrary selected old version), and maybe even version of 
feature. Feature name is the key in FEATURES dictionary, value 
corresponding to this key could provide additional information.

I can't say how it works in the long run, because I've added only one 
item to FEATURES: qignore. Using qignore feature I was able to implement 
proper backward-compatible support in bzr-explorer around qignore.

I remember sometimes in the past, when we had forced to update QBzr or 
some other plugins because of small but annoying changes in bzrlib, I 
wished to have an intermediate proxy on top of bzrlib API that could 
adapt to minor API changes in bzrlib and provide a consistent interface 
to bzrlib internals required by QBzr needs.

If you look at QBzr internals you could see that only small amount of 
q-commands works with bzrlib API directly, and all those commands are in 
fact "browsers/viewers" (browse log, working tree/revision tree browser, 
diff viewer, annotations viewer).

Most of q-commands provided by QBzr are just front-ends to construct 
valid bzr command line and execute `bzr blah...` as subprocess. This 
approach has proved to be very successful - we cover most of the bzr CLI 
required by bzr-explorer without any effort from our side to keep 
compatibility with bzrlib internals.

So, maybe reducing the amount of public bzrlib API will help here? Or 
provide some consistent set of methods as an adaptor between plugins 
needs and bzrlib internals? Of course plugins authors should understand 
what they need from such interface. Of course plugins like bzr-svn or 
bzr-git won't need such adaptor, they have to dive deep into bzrlib.

Maybe such adaptor could be a core plugin? I'm not quite sure.
But such adaptor should be very conservative to able to operate with old 
versions of plugins. Maybe such adaptor could provide new bzrlib 
features by new names, so plugins could get benefits of using newer 
features if they are aware of it.

I know there is too much "if" and "maybe", but this is what has been 
sitting in my head for a long time.