In response to Marcus;
For furture releases we should think about to decrease limits, e.g.,
introduce newer baseline requirements for the OS.
However, this is not for the current release line (4.x). It would be
uncommon to do such kind of changes with the next release.
I am not really think of version numbers here, we cannot limit
development due to older release policies (which should be revised).
Right now the problem is the older toolchain is limiting future
development. Newer versions of MSVC come with new features
that help and limiting ourselves to support EOL'd OSs like W2K
is not a good policy. This said, there is no point in discussing this
now as no one has done the heavy lifting.
I also forgot to mention:we should not spend any time on mingw,
it never worked for AOO and having clang already working it seems
the logical alternative for using an alternative open source compiler
on Windows.
We should announce first what we want to change with a bigger release in
the future - like baseline req for Linux, marking old APIs as
deprecated, rethinking the minimal Java version, etc.
This is not going to happen because "we decided it" someone has to do
it and it will likely not decide the release schedule.
<In response to a different posting>
How big is the effort to do the opposite first?
Copying your branch into a clone, updating it with the current Trunk, do
needed cleanup and fixes and then see how stable the builds on all our
supported platforms are.
It is indeed common practice to sync the branch with trunk before merging
it back. In this case, however, the changes in trunk have been so minimal it
is not necessary.
Pedro.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
