Sorry for the late answer, we had a public holiday yesterday:
[...]
I agree, but since a lot of this stuff had co-dependencies (e.g. 64bit JRE
-> 64bit UNO -> XCode4 -> clang -> allows C++11 -> no-stlport4 and XCode4
-> newer SDK) it wasn't easy to come up with a name that covered the
different aspects. "Platform refresh 2013" and "rejuvenate" were the only
ones that came to my little mind. Maybe I should have asked around more for
better ideas. In my defense I mentioned the name "pr2013" as a suggestion
for the branch in my 2013/04/09 mail on the XCode4 topic and nobody
complained or had a better idea then.
You are right with that lot of changes "rejuvenate" is quite precise (now
I just start wondering what rejuvenate02 is going to contain)
With the two-digit extension we'll have enough room to rejuvenate our
Office many more times ;-)
As to a concrete rejuvenate02 branch there are no concrete plans, only
some general ideas:
- Maybe now that the branch rejuvenate01 replaced stlport4 by a standard
compliant STL from a binary perspective a new branch rejuvenate02 could
be the followup for the related cleanup in the main codebase? Since this
can mostly be automated I'll probably do it r01 though.
- A rejuvenate03 branch could use all the C++11 features that are
already now commonly available on our platform's compilers to clean up
our codebase
- A rejuvenate04 branch could go to full C++11 and improve speed using
rvalue semantics and auto-types could help to make some areas much cleaner
But what's in a name anyway. I just want to keep us the options open,
but I don't like to concretely plan such stuff years ahead. Such
concrete long-term plans would only limit the flexibility and close
options that could benefit the project.
I have one technical question, how come you can change so easily to STL,
when it took LO many volunteers to do it, or did I misunderstand something ?
Because of the license incompatibility I have no idea what they did and
so I don't know why it took so much effort. Maybe they also converted
some other ancient OOo data structures to STL?
Or maybe they did the changes needed individually? I prefer to isolate
the individual transition concerns (using my STL-wrappers and their
STLPORT4-emulation), do the main transition (e.g. from hash_map to
unordered_map) automatically and then drop the STL-wrappers altogether.
If we have volunteers who like to boost their committer statistics we
could to the main transition manually and per source file though ;-)
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
