On 18-Jun-08, at 8:29 PM, Dan Fabulich wrote:
Brett Porter wrote:
3.0-alpha-1: released as is, with or without those few fixes I was
looking at getting in.
3.0-alpha-X: later introduce the mercury and SAT based stuff as an
optional component
3.0: when all the above is stable and the resolution method is
selectable
Is that how everyone sees it going?
It's not clear to me how we want to treat the defaults here; I think
this has big implications for the Maven 2.1.0 release.
Brian had argued earlier that we need the "new" (SAT?) resolver
before we can release 2.1-alpha, because it will require lots of
soak time and feedback.
But if the SAT resolver is off-by-default and 100% configurable,
then we DON'T have to get it settled before 2.1-alpha; we might even
release new/improved versions of the resolver after Maven 2.1.0 is
released. SAT might not become the default until the next major
release (3.0) at which point backward compatibility breakages would
be more acceptable.
On the other hand, if we do intend to turn on a new/improved
resolver by default, then we need to get it into 2.1-alpha, and we
should all do whatever we can to get maven-artifact 3.0 100%
finished ASAP so we can get a release out the door, without which we
will never add a new feature ever again. :-)
For my money, it sounds like the SAT differences will be significant
enough that we can't turn it on by default, so we have to leave the
old resolver in, so we can/should ship a 2.1 alpha without it.
Thoughts?
We're never going to get 2.1-alpha-1 out soon even with the 39 issues
that are scheduled and the alphas are going to be caveat emptor.
Before 2.1 is shipped the new resolver will go on by default with an
option for backward compatibility. Ranges just don't work and won't
without the SAT solver, and ultimately it is the only mechanism that
will be technically correct. Stability is required for 2.0.x, for 2.1
we should do our best, but provide a correct solution going forward
with an option to revert to account for bugs, if they in fact cause
problems.
Between Oleg, Daniel La Berre, and myself we'll find a workable
solution before the betas. For now I think we release maven-artifact
as is because the primary consumer of this is the embedder and
therefore IDE integration and risking changes there now is not a good
idea. The 2.1 final is still months away and anyone who touches the
alphas knows they are playing with fire. The ultimate goal is correct
artifact resolution so what's currently in place doesn't cut it as a
long term solution.
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
