Here are my two points: 1. Our current versioning scheme requires patch versions for all releases, regardless of quality 2. We need to be able to do "alpha" releases to get new, experimental features into the community for testing
These two points, put together, will necessarily result in a 2.1.0 release that is drastically different than 2.1.1. I just don't see any way around that. As for your other point about dependencies, well, that problem goes away once the convention plugin is bundled with Struts, because it will then have the same version number and will necessarily be compatibility with its counterparts in that release. As for third-party plugins, yes, that is an issue, but I don't see how it is any different than any other library. My app depends on Velocity 1.5, but a library I use depends on Velocity 1.4, so problems could arise. We have this all the time in the projects I work on, so I don't see how Struts is unique here. Don On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
