Don Brown wrote:
Well said, and I completely agree. My original point is your point #1
just isn't possible with the current versioning scheme. Because every
release gets its own patch number, regardless of quality or API
changes, it can't be counted on, and really, I don't see any solution
other than creating a big matrix of releases for users to somehow
navigate the sea of releases to understand which are compatible with
the other.
I agree with you on that. It is difficult. However, it doesn't mean that
a person or tool couldn't check the public APIs for changes prior to
doing a release. The release would not ever occur and remain in
-SNAPSHOT until those broken APIs are fixed.
From the other thread:
I do agree we need to be much better about how much of our API we
expose to developers, but I think the question of public vs private
API goes beyond the Java semantics and into what a typical Struts user
will encounter. Unless you are a plugin or framework developer, it
would be very rare for you to be creating configuration objects, so
yes, while these are technically public, I'd certainly call them more
private than, say, the Action interface.
It is actually more complex than I think you realize. Here is another
dependency graph that reveals a really bad issue:
Project A -> struts 2.0.6
Project A -> library B
Project A -> library C
library B -> convention-plugin 2.0.6 -> struts 2.0.6
library C -> struts 2.1.1
This graph is broken because the build will decide that 2.1.1 is the latest and
most correct version of Struts to use and put that in the classpath. However,
the API changes in 2.1.1 break the convention plugin. BUT struts 2.1.1 doesn't
depend on the convention plugin 2.1.1 and therefore the build is incapable of
warning the user that things are broken and cannot manage this graph correctly.
So, any public APIs need to be managed and when you introduce transitive
dependencies, things get complex. Applications will break, even if they don't
use those public APIs directly.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
