Felix Röthenbacher wrote:
Michael Wechner wrote:
Felix Röthenbacher wrote:
Michael Wechner wrote:
Hi
Somebody has removed the
lib/excalibur-io-1.1.jar
library although I have added it just recently such that Lenya is
backwards compatible.
Lenya is still backwards compatible as the functionality of the
deprecated excalibur-io-1.1.jar is provided by the new commons-io
library.
maybe the functionality, but not the API, or am I missing something?!
I don't want to get into a commit war, but this library is
necessary for staying backwards compatible.
To me, it's seems to be impossible to stay backwards compatible with
code that is open-source.
I am not going to use a strong way ;-) but that's not true at all!
What difference is there between Open Source and closed source re
backwards compatibility?!
A closed-source software vendor can rely on that no one uses
any internal functions and he is free to modify internal processing.
exacliabur is not only about internal stuff. Lenya/Cocoon used in order to
prevent the not invented here syndrom and this is the case for many
libraries,
so it's not just about internal stuff
Open-source Lenya may be adapted and modified in any way, that's
open-source.
no, not if the dev community resp. PMC decides to stick to backwards
compatibility
It would be best to publish a well-defined API for access to
Lenya. Then I would agree that if Lenya does not touch the API
it will be backward compatible, but that's not the case at the moment.
it is the case. Just because the API might sound as official as JCR for
instance, it
doesn't mean it's not an API and we need to guarantee that the same is
true for
the libraries which are being used by Lenya
Everybody can do what he wants with the code
but must be aware that it will change in the future (with the exception
of well-defined and agreed-on API's). Staying backwards-compatible
would
mean that you can't modify any functionality, even if it's buggy:
"bugs" is an exception to the rule
someone might rely on it and may even exploit the bug for achieving
some tasks (see browser implementations of non-standard CSS).
It's not sufficient to upgrade Lenya itself, but one needs to keep
in mind, that other people
might have built publications based on this library.
Taken this into consideration, see my comment above. The changes
re the library replacement are minor. The functionality is
provided by the new library. With respect to code maintenance it's
better to jettison deprecated libraries and keep a clean code base.
no, it's very clear what backwards compatibility means and if a
community agreed to
stay backwards compatible within a branch and people are relying on
it, then one
needs to stick to that committment, doesn't matter what it means to
the code base.
This would mean to commit Lenya to a specific Cocoon version, as the
on-going Cocoon development will break backward compatibility,
the problem is, that Cocoon shouldn't break backwards compatibility
within a branch,
at least that's what I understand from their dev community. If that's
not the case, then
we have various choices. Either stick to certain specific Cocoon version
or use something else
than Cocoon, or ...
as seen
recently with the library replacement. We should think again about
saying that Lenya is compatible with Cocoon 2.1.7, 2.1.8 and 2.1.9
as this can't be assured (e.g. Cocoon 2.1.7 is not compatible with
2.1.8).
but that's exactly the problem and I will send an email to the Cocoon
mailing list about this
and I think we all should complain about this.
What if a library of Cocoon changes functionality keeping its API.
Then it will not be possible for Lenya to add the old library as
there will be conflicts (seen with commons-io-1.0.jar and
commons-io.1.1.jar). What if Lenya relies on an library xy-1.0.jar but
Cocoon request library xy-1.1.jar and the two libraries are not
compatible? It's an imagination to say that Lenya is backward compatible
re its codebase as this can't be assured.
it might be not always possible for whatever reasons, but in this case
it is and
we as community should do everything to make this happen.
I think it's rather simple:
1) Apache Lenya (and the ASF) decides to develop high-quality Open
Source software which is going to be used
within the entrprise world and of course all the other worlds as well ;-)
2) The enterprise world (and not just the enterprise world) is asking
for backwards compatibility for various reasons
3) From 1 and 2 it follows that Apache Lenya needs to be backwards
compatible
I am very confident that this is possible (at least in most cases,
whereas there are exceptions, e.g. bugs, etc.)
and we as a community have to make sure that we stick to 1 and 3,
otherwise we loose the trust people do have in us
and the project re its goal will fail very qickly.
One can certainly re-discuss the goals and its consequences, but as long
as the goals/rules are in place one
has to make sure to stick to them as good as one can, otherwise the
communuity/society will fall apart very quickly.
Michi
- Felix
Without backwards compatibility there will be no-one using it, except
people who
don't use it in productive environments or have infinite resources at
hand to upgrade
all the time.
I am not saying that this is a bad thing, but the Lenya community and
Apache in general has
decided to create software on which people can rely on and backwards
compatibility is one of
the keys to this.
Michi
No commit war, just my 2 cents :-)
- Felix
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
