On Sat, Jan 29, 2011 at 04:33, Jason Porter <lightguard.jp@gmail.com> wrote:
On Fri, Jan 28, 2011 at 16:36, Jordan Ganoff <jganoff@gmail.com> wrote:
> Except releases would then no longer be 100% reproducible. Probably comes
> down to a matter of policy.

This is a very big reason why not to use ranges for versions, of
course it's all pretty much thrown out the window at runtime because
which jar happens to be loaded first (and maven will use the most
current if anything references a more current version) wins.

I'm with Jordan on this one, I say no version ranges for sake of
sanity in trying to reproduce builds.

I agree, version ranges are a thorny path to go down. However, keep this in mind. The version of Solder is the minimal API compatible version against which the modules compile. The end developer can simply drop in the newer version of Solder and instantly get the performance boost. Especially in this case where the change is internal to the Solder impl. They can even upgrade the impl without upgrading the api jar.

Naturally, they would want to run their own test suite after the upgrade just like when you upgrade any version.

Sound reasonable?

Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597