Jason, The issues I'm finding (or my userbase actually) are not with mevenide integration. It's also not something I could test on my side. It's in 99% of cases incompatibilities with 2.0.x. And it's not a reoccuring pattern, no trunk-to-trunk regressions. So no test could save me from it anyway. And *if* I wrote tests, it would be in maven not mevenide. That's where it belongs IMHO. So please don't make it sound like it's my own fault anyway.
more inline On Sun, Aug 10, 2008 at 10:18 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > 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. well, any of the 6 or so snapshots I've used in the past 6-8 months had some (different) rough edges. So from my perspective it can be current trunk, no need to go backwards. > 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. It's all cool and I want it in the released bits just as you do but it IMHO pushes the release into more distant future. That's what I was pointing to my previous emails. regards Milos > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
