Hi *,
seconding Jürgen's heads-up that this list infrastructure will soon
cease existence, let me also point you to LibreOffice and The Document
Foundation. When the OOo extension site became more and more unstable,
we decided to setup our own extensions and templates repo.
LibreOffice and The
Hi Malte,
you wrote:
I think it's better to break AWT API compatibility once, instead of many
times in many releases.
Which really also might turn out as never - the unlikeliness of
the big-bang-change to happen was already pointed out (since when
are we talking about awt redesign? I
Mathias Bauer wrote:
Frank Schönheit - Sun Microsystems Germany wrote:
I'd say we need a set of highly proficient and highly respected
architects, whose opinion should, at least, be weighted high.
No, please not!
Hi Mathias,
FWICT Frank was joking here. ;)
Of course (as for every
Stephan Bergmann wrote:
On 04/28/09 14:27, Thorsten Behrens wrote:
well, Win32 is only one platform, and experience tells that in
general, c++ extension *do* break between releases. But you're
right, that's not necessarily caused by ABI changes in the strict
meaning of the word, a case
Mathias Bauer wrote:
well, Win32 is only one platform,
:-) It's the platform of the overwhelming majority of our users.
Hi Mathias,
well, the question of *how* overwhelming the majority is, that's
indeed interesting (though largely off-topic here, I fear) - what
might be the number of
Frank Schönheit - Sun Microsystems Germany wrote:
[lots of valid points]
Hi Frank, no disagreement whatsoever.
Who decides?
Difficult ... Having a gatekeeper (or multiple fatekeepers) does not
really sounds feasible. I would hope that discussing the changes in
public until a consensus is
Frank Schönheit - Sun Microsystems Germany wrote:
oh, I was under the impression the author is referring to c++ - so
then, it's Java? Should we add Java to the list of fragile
extension implementations as well? ;)
Not sure you're doing the topic a good with this
The mentioned
Mathias Bauer wrote:
limit impact considerations to non-ABI-dependent UNO bindings
(i.e. the assumption is that c++ components break randomly anyway
for every other release, so they shouldn't block API changes)
This is not true; in fact on Windows C++ extensions are very stable and
at
Stephan Bergmann wrote:
On 04/28/09 14:27, Thorsten Behrens wrote:
well, Win32 is only one platform, and experience tells that in
general, c++ extension *do* break between releases. But you're
right, that's not necessarily caused by ABI changes in the strict
meaning of the word, a case
Hi *,
on the last ESC meeting, we had a little brainstorming about if and
how to deprecate OOo API. The 'if' was unanimously agreed upon,
for the 'how' we came up with the following thoughts:
API deprecation
===
See
Hey Juergen, *,
Juergen Schmidt wrote:
Before we start discussing it in more detail, please can we agree
to continue on one mailing list only. I would suggest to continue on
the dev@api.openoffice.org list because it is API related and the
correct list for it.
Personally I don't want this
$subject has been discussed on and off for quite some time - as of
now, the law is you must not change published (UNO) API. I'd like
to challenge this very rule, since (as all absolute rules) it's
silly in practice hinders cleaning up cruft, of which there's
abundant in OOo.
To spark some
On Tue, Jul 22, 2008 at 10:46:58AM +0200, Juergen Schmidt wrote:
By the way i set your patch to invalid because i think such a whitelist
is the wrong mechanism. We already have the possibility to make
incompatible changes at the reference rdb but it is not publicly
documented and should
13 matches
Mail list logo
