My numbering has nothing to do with yours...
1. The versioning manifest described in [1] used to be at
http://cocoon.apache.org/versioning.html. Somewhere along the line that
page was apparently removed. Probably because it wasn't being followed.
There was a followup thread a while later where many committers didn't
even remember we had passed this.
2. Personally I think 2.2 should be 3.0, but that is just me. Because of
that I have no real problem breaking binary compatibility with it and so
I definitely don't have a problem with what you are proposing there.
3. Welcome to the club. We've all been depressed at one time or another
over how infrequently we do releases. But the list of issues shouldn't
end there. For one, your original fix shouldn't have been able to go in
without causing the build to test. The number of unit tests we have is
abysmal. We can drastically improve this in 2.2 since maven makes it so
easy to build and run them, but I don't think it is that hard in 2.1 either.
I kind of find it amusing that you checked in this change 3 months ago
and no one has noticed until now that the JXPath modules are all broken
- at least on getting the values of elements anyway. Attributes still work.
In the end I'm probably just going to let this slide unless someone else
responds and says it will be a problem for them, partly for the reasons
you cite with regards to JXPathHelper, partly because the existing
method is a bit odd and partly for other reasons.
I'll add the new method and fix the other classes as part of checking in
XPathXMLFileModule (ironically, I made a new class because this version
is not quite compatible with XMLFileModule).
Ralph
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
So you have no problem breaking API contracts with end users on minor
point releases?
To be honest I was thinking about 2.2 mainly. Anyway, I agree with everything
that has been said in
the thread[1] mentioned by you but at the same time I see some subtle details:
1. JXPathHelper, even if not marked explicitly, should be considered as rather
internal class. It
has absolutely no Javadocs and does not look as a standard API.
2. Current behavior of getAttribute() method does not fulfill any API's needs
as there are no
documentation on how it is supposed to work. What's more current behavior is
completely different
from what one could expect taking
javax.servlet.http.HttpServletRequest.getAttribute() as an example
of similar functionality.
3. We are really bad on releasing and desperately bad on making minor releases.
It was clearly shown
by Antonio: http://article.gmane.org/gmane.text.xml.cocoon.devel/76241
I'm not sure if it's just me not being in good condition overall but when I
read this list compiled
by Antonio and realize how long it takes to make a patch release I become
really depressed. Don't
you think that waiting about three to four years to remove (first deprecate)
some old code is too long?
[1] http://marc.info/?l=xml-cocoon-dev&m=108266407019215&w=2
