On Sat, Jan 29, 2011 at 06:43, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Sat, Jan 29, 2011 at 04:33, Jason Porter
<lightguard.jp(a)gmail.com> wrote:
>
> On Fri, Jan 28, 2011 at 16:36, Jordan Ganoff <jganoff(a)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
I'm fine with that, and the fact that we're doing two week time box
releases, a little perf issue like this isn't a major issue. We had
perf issues with Weld for how long?
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
PGP key id: 926CCFF5
PGP key available at:
keyserver.net,
pgp.mit.edu