Don Brown wrote:
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.
Tooling can solve this issue.
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.
It doesn't go away because although it is bundled with struts, it is a
separate JAR and that means it is a separate dependency inside pom.xml,
project.xml, ivy.xml etc. The case I gave is real and folks have run
into already with smart-urls and will run into it with other plugins,
even those bundled with Struts.
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.
They won't arise if the tool (i.e. savant) knows how Struts is
compatible across versions. If we state that struts is ALWAYS compatible
across patch versions (ie 2.1.0 and 2.1.1) than the tool can correctly
pick the latest version. Or in the case below, it will produce an error
because 2.0.6 and 2.1.1 are not compatible. Let the tool do the heavy
lifting of managing all the dependencies including transitive. That's
what maven, ivy and savant are designed to do.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
