I think having the intermediary bridge is a good idea, and I would be
comfortable finding the last stable version of trunk that works with
Mevenide and then release that and then leave that as a stable branch
for you to work off.
One of the problems is that your code seems not to be very testable
from your own description and there's nothing we could run to validate
changes in trunk haven't busted you without you manually testing. You
have to do something about that because asking you to manually try
things isn't tenable. We'll make the stable branch of 3.0.x, and then
we can leave that pretty much static except for bug fixes you want to
put in there.
I need a release just as badly as you for the Eclipse IP process. So
if you we can match what you're using and find that point in time
where you're happy we'll roll back trunk to there, cut a 3.0.x branch
and you will have something stable. I want to continue getting Mercury
and Shane's new project builder in because to me that will be a
massive stabilization in the artifact mechanism and Shane is just
tearing out all sort of cruft that's built up in the POM builder and
we're just not going to be able to create a spec'd process, mixins
support, multi-format/version support, and a many other things with
these two changes.
Releasing trunk as 2.1 I think would be a very bad idea, but I'm happy
to rollback/patch to whatever point in time makes you comfortable. I
would prefer to plough along on trunk which looks like would become
3.1.x in this scheme. You would probably stay away from Mercury and we
are really going to need a harness from you we can run. The ITs will
get better and be protection at the CLI level but you seem to keep
getting bitten at the embedder level.
Let me know what you would like to do.
On 10-Aug-08, at 10:37 AM, Milos Kleint wrote:
On Sat, Aug 9, 2008 at 11:32 AM, Mauro Talevi
<[EMAIL PROTECTED]> wrote:
Milos Kleint wrote:
please, please, let's not add anything else to trunk (2.1) and
stabilize it. I've been waiting for a stable embeddable version
for 2
years and with the number of work (complete rewrites of everything)
in the branches, a stable maven.next looks years ahead again.
Not having an embeddable maven that works in the IDE integrations
hurts the adoption and trust of users.
Milos, isn't just a case of renaming trunk/2.1 to trunk/3 ?
well, the version number itself is of little interest to me, but I see
a lot of people cooking new stuff at branches. I suppose the intention
is to get this code into trunk. The question for me is wheher it gets
into trunk before the maven.next is released or after (be it 2.1 or
3.0 ). The maven.next that's interesting to me is the version that is
embeddable.
Also cutting an alpha or beta would enable IDE devs to work to that
without
having sleepless nights about stabilisation.
Well, if the alphas and betas get cut from a stable branch that will
ultimately become the next final release, I'm cool with it.
Milos
Cheers
---------------------------------------------------------------------
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]
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]
