Changes needed for "LibreOffice 4"

[Lubos Lunak]

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.lunak at suse.cz