On Thursday 19 of July 2012, Michael Meeks wrote: > * 4.0 - when to call it that ? (Kendy) > + extension downloads > + some quite popular PDF import 3m downloads > + mysql - 330k > + spellcheck dicts - 300k > + renaming com::sun::star a problem here, > + instead perhaps announce rolling flag-day (Caolan's plan) > + http://wiki.documentfoundation.org/Development/LibreOffice4 > + too much to do in one six-month section > + top of agenda for next week.
I think one of the first things that need to be done is actually saying what "LibreOffice 4" means. Looking at the wiki page linked above, apparently that's not clear at all. I see 3 reasons for why we should have LibreOffice 4 (not necessarily exclusive): a) for marketing reasons - we want to be like Firefox, we want to match AOOi (who AFAIK might go to 4.0 somewhen soon), or similar completely non-technical reasons b) we do significant user-visible changes, such as UI rework, or something that make the new LO version quite different from the previous ones c) we break backwards compatibility As a) is not technical at all, there's not much point in discussing it on a development list. If that needs to be done, we stamp "4" on it and it's done. Option b) is actually rather similar to a) in that if it's decided to be done, we just do it and that's it, it just will be more work. I'm not aware of anything significant in this area that'd warrant this, so I think we can ignore this one (correct me if I'm wrong). Option c) can mean either stopping supporting some file formats, or breaking API/ABI compatibility. For file formats we want to do this with binfilter AFAIK, nothing else, and this is a lot like b) as well in that it's just done and that's it. Breaking API/ABI compatibility for LibreOffice means breaking (only) extensions, which depending on the changes may need recompiling, adjusting or complete overhaul. Now, if you look at http://wiki.documentfoundation.org/Development/LibreOffice4 , a lot of the stuff there does not belong to the page at all, as it has absolutely nothing to do with any of the above: - "get rid of ASCII graphics noise (//=================== etc)" is actually an EasyHack that just should be created as such, and can be done at any time without affecting anything else. There are a number of items in the list like this. - "de-UNO-ize the ODF import and export filters." is a purely internal matter that does not affect anything outside of LO core (or am I wrong here?) and as such it can be done at any time. Again, nothing to do with LibreOffice 4 (unless we want to use "4.0" as an excuse if things go wrong). There are several more like that. So, as long as we decide to do c) when switching to LO4 (which AFAIK we plan to do, even if c) alone is not the reason), the page first needs to be cleaned up to contain only items that actually do have something to do with LibreOffice4. And after all this is done, it should be easier to actually talk about LO4, because we'll know what the talk is actually about. As for the technical details (i.e. c) ), we'll need to decide how to handle the breakages it'll cause for extensions. Note that as extensions use only URE (right?), affected code is actually relatively small (AFAIK sal/, salhelper/, cppu/, cppuhelper/, udkapi/ and offapi/, not sure about the last one). I see roughly several ways: 1) We say we don't care about backwards compatibility, and keep possibly breaking it every release. Extensions will need to check they run with exactly the same version they were built for. + easy for us - more work for extension developers (#ifdef's , they'll either support just newest LO, or need to provide several versions) 2) We break compatibility once for 4.0 and keep it again afterwards. IOW like we've done so far. + extensions will need to be updated once and then it'll stay the same for them - we need to manage to do this between 3.<last> and 4.0 , which may be quite some work and risks the KDE4.0 fate and the bad options (release too late, release too buggy, get stuck with stable 3.x and never stable 4.x); I have some experience with this from the KDE times and, unless we find out we don't actually have much work in front of us, we probably don't want to go there 3) = 1)+2) - we break it at 4.0, keep going with 1) until we're confident enough we can manage 2) again + easy for us (we just should end up with decently designed APIs for extensions, or we may need to do this again) - more work for extension developer, until we enter 2) 4) We do 2), but we smooth it out with a transition period (backwards compatibility wrappers). I believe that a number of the LO4 changes can be done in a compatible way with just a little more work (I have quite some experience there from the KDE times too). For example, the com::sun::star::* -> uno:: change is probably doable in 3.x by introducing the new names that would map to old ones. This would allow us to test this already in LO core without affecting extensions. Another example, if we change rtl::OUString, we may rename and change it for LO4 and keep the old one for backwards compatibility. In short, this is 3) where we put more work into not breaking extensions. + extensions will need to be updated once, or possibly even not at all - may need some extra work (although it's a question of how much) - possibly some code duplication (although the old code may be later removed, so this may be just having a time overlap with the new/old code) - if LO4 needs to be out soon for whatever reason, we may not have the time I'm not going to say which solution would be the best, because it depends on what we expect from "LibreOffice4" (how much we are actually going to change, how much we care about extensions, etc.). So for that, we should first decide on what "LibreOffice4" will mean. Summary: - it needs to be said what we expect from "LibreOffice4" - the wiki page with technical tasks needs to be cleaned up - we need to decide how to deal with the fact that LO4 will break backwards compatibility -- Lubos Lunak l.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
