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

[Jelmer Vernooij]

Am 15/03/12 16:29, schrieb 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.
<snip/>
> 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.
Why does it have to be a proxy? Is there any particular reason we
shouldn't just make the changes in bzrlib itself more robust by e.g. not
adding non-optional arguments?


> 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.
Is the relatively low number of issues you've seen with qbzr due to the
fact that the command line interface is used, though? bzr-gtk uses
roughly the same functionality as qbzr but through the bzrlib API and it
also hasn't seen as many issues. I think for the majority of plugins
which use the well-known stable APIs we haven't seen many issues. It's
the somewhat lower level APIs that are more prone to changes that are
problematic.
>
> 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.
Is there a particular reason this has to be a features dictionary,
rather than e.g. an object in a module the plugins could look for ? This
is how bzr-svn/bzr-git/bzr-hg do most of their compatibility checking.

Cheers,

Jelmer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120315/cf032056/attachment.pgp>