Re: [Libreoffice-qa] minutes of ESC call ...

On 16/12/16 09:28, Bjoern Michaelsen wrote:
> On Fri, Nov 25, 2016 at 12:02:03PM +0100, Michael Stahl wrote:
> > since the goal of the policy is  "we can make incompatible changes
> > whenever it doesn't affect any 3rd party extension or macro", the
> > "published" tag is much less useful as guidance than it may appear at
> > first glance.
>
> So, uhmm, if the current/old use of "published" doesn't service core developers
> and doesnt serve UNO users, maybe we should consider making it useful ? A
> radical step would be to remove the "published" tag everywhere (as we allow
> ourselves API changes anywhere already) and then carefully readd them in areas
> where we are reasonably sure we dont have to break the API again soon.

        Hmm ! ;-) My concern would be that removing the 'published' tag
everywhere would end up making it much harder to change all UNO APIs.
There is a spectrum of views on how conservative (or otherwise) we
should be around changing published APIs ATM, and how to do that but

        so far - I've not heard anyone articulate the view that an un-published
API cannot be easily changed =) so - there is at least -some- hope for
improvement of -some- of the UNO APIs without sterilization of the whole
space[1]. Personally I'd never create a new API that is published ;-)
but ...

        Are we truly sure that removing the 'published' keyword in averaging
this out would help everyone adopt a more flexible, comprehensible and
positive approach ? I fear that we'd go entirely the other way and have
problems everywhere ;-)

        Given what UNO promises, I would imagine that the best place to invest
work here is with some focus on future-proofing things. As far as I can
see, there are a ton of exciting possibilities when you can capture so
much type information on both sides. It should be possible eg. to add
parameters to methods, and append methods to existing interfaces if the
right work is done in the bridging - and if we engineer around default
values for those parameters. Similarly, as Kendy pointed out there is no
fundamental reason why we can't extend enumerations etc. if we get the
bindings right. Which reminds me - this is prolly a great item for the
budget / funding discussion =) I'll try to file an item with a better
spec. there

        ATB,

                Michael.

[1] - sure we can have a policy, sure it can be written down somewhere -
the theory is all good - but the 'smell' of badness, relational pain,
extra work, etc. that surrounds UNO is already bad enough IMHO without
making the situation less clear.
-- 
michael.meeks@collabora.com <><, Pseudo Engineer, itinerant idiot