Code review comment for lp:~mir-team/mir/expose-debug-buffer-id-to-client
Revision history for this message
| Robert Ancell (robert-ancell) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
> > For libmirclient we are providing stability, so a Mir update doesn't break
> > mesa/XMir etc. Just mark functions as deprecated and we'll remove them in
> one
> > big change (libmirclient1 -> libmirclient2). If you really want to get rid
> of
> > a function now, then you have to bump ABI but this will probably be more
> work
> > overall than just leaving the old function there.
>
> I hope the same goes for protobuf too? (that we'll just clean up all dead code
> at once to minimize disruption). I'd feel better if this cleanup/old-api-
> breakage was scheduled at regular intervals or something (every three months
> perhaps), just so we keep bloat at a 3-month maximum.
protobuf is harder - because we can't stop any old client connecting we have to be able to handle that case. In practise, one we have bumped the ABI on libmirclient we can drop old protobuf changes (since we know all the clients currently). But we can only do this in this phase of the project - once we are widely distributed we can't do this any longer. Also make sure to make a note in the .proto of old field numbers that have been used to avoid weird binary mismatches.