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.me...@collabora.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice