On 11/08/2008, at 3:23 PM, Jason van Zyl wrote:
So it looks like the general consensus is:
- Cut a 2.1.x branch from a 2.0.x tag (I saw 2.0.9 and 2.0.10 float
by as options)
- Call trunk 3.0-SNAPSHOT
We'll just bugfix 2.0.x. The 2.1.x branch will be the mediator
toward 3.0, and given t
So it looks like the general consensus is:
- Cut a 2.1.x branch from a 2.0.x tag (I saw 2.0.9 and 2.0.10 float
by as options)
- Call trunk 3.0-SNAPSHOT
We'll just bugfix 2.0.x. The 2.1.x branch will be the mediator toward
3.0, and given the mediator exists we're a lot safer doing a 3.0-
On 10-Aug-08, at 9:05 PM, Milos Kleint wrote:
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 re
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
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 te
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 ev
gt; these bigger destabilizing fixes/small features to a 2.1 branch cut
>> from
>> > 2.0.10. Unless 2.0.10 gets worked out real soon, perhaps we even go
>> back
>> > to 2.0.9 and branch there (ie 2.0.10 becomes 2.1.0)
>> >
>> >
>> > -Origi
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 a
Brian E. Fox wrote:
I have been saying that the trunk is too changed for 2.1 for a while
also. I think having it as 3.0 is probably the logical thing to do and
then we can really buckle 2.0 down as it should be and start making
these bigger destabilizing fixes/small features to a 2.1 branch cut f
m
> > 2.0.10. Unless 2.0.10 gets worked out real soon, perhaps we even go back
> > to 2.0.9 and branch there (ie 2.0.10 becomes 2.1.0)
> >
> >
> > -Original Message-
> > From: Brett Porter [mailto:[EMAIL PROTECTED]
> > Sent: Thursda
.1.0)
>
>
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 07, 2008 11:16 PM
> To: Maven Developers List
> Subject: Re: Versioning Maven (was: Re: Maven 2.1 development IRC
> roundtable)
>
>
> On 08/08/2008
development IRC
roundtable)
On 08/08/2008, at 12:24 PM, Paul Benedict wrote:
> Is TRUNK really 3.0? Hmm.. Maybe not. I think it is only appropriate
> to bump the first number when you make a major architecture change. It
> was totally appropriate between 1.x and 2.x because the code
On 08/08/2008, at 12:24 PM, Paul Benedict wrote:
Is TRUNK really 3.0? Hmm.. Maybe not. I think it is only appropriate
to bump the first number when you make a major architecture change. It
was totally appropriate between 1.x and 2.x because the code bases are
absolutely incompatible. Why I shou
Is TRUNK really 3.0? Hmm.. Maybe not. I think it is only appropriate
to bump the first number when you make a major architecture change. It
was totally appropriate between 1.x and 2.x because the code bases are
absolutely incompatible. Why I should believe the same for TRUNK now?
It still looks lik
On 08/08/2008, at 5:45 AM, John Casey wrote:
This is exactly why I'd like to put the current trunk code on the
path of being released as 3.0. We have tons of things that could
reasonably be improved in 2.0.x, but aren't really appropriate in
such a minor release as 2.0.11. We could move
not a bad idea john...
the major concern I would have is that 3.0 in this case is already the
basis of all the embedder work (ie IDE development) while the
2.0.x->2.1 releases would in essence have to be forward compatible
with 3.0 because of that...the build in the IDE _ought_ to work the
same as
> This is exactly why I'd like to put the current trunk code on the path of
> being released as 3.0. We have tons of things that could reasonably be
> improved in 2.0.x, but aren't really appropriate in such a minor release as
> 2.0.11. We could move toward larger feature introductions like import
Anything should be visible on the proposals page. I will put my
gathering document in the wiki tonight.
But I'll link in what you've high lighted so far. So just mentioning
it is good enough, I'll integrate it.
On 7-Aug-08, at 12:51 PM, John Casey wrote:
So, where are we collecting all of
IMO, this is also relevant, though is hasn't been implemented:
http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C+and+Replacement+of+Plugins+and+Mojos+Bindings
Jason van Zyl wrote:
On 7-Aug-08, at 9:21 AM, Brett Porter wrote:
On 08/08/2008, at 1:04 AM, Jason van Zyl wrote:
So, where are we collecting all of this information? I'm digging up some
of the proposals that I wrote up in the past couple years, some of which
I've already implemented on trunk (and IIRC all of which have been
floated on this list).
A lot of these things already exist, they just need to be
Wendy Smoak wrote:
On Thu, Aug 7, 2008 at 9:27 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
We can call it whatever version. At this point I don't think it much
matters.
I'd like to see the current trunk moved to a code-named branch, so
that we can make incremental improvements in 2.1, 2.2,
Sure, we could do this at a conference that most people are going to,
or organize something ourselves.
On 7-Aug-08, at 10:34 AM, Arnaud HERITIER wrote:
One thing that we could also do is to have a meeting together one
time per
year.
I know that some dev teams are doing it (groovy for exampl
One thing that we could also do is to have a meeting together one time per
year.
I know that some dev teams are doing it (groovy for example) just before or
after an event like JavaOne.
They work together during 2 or 3 days to analyze their project and to
prepare the future.
They share their experi
If you are actually helping to develop the core code then I'm sure
that's definitely one of the approaches we could take.
On 7-Aug-08, at 10:18 AM, Wendy Smoak wrote:
On Thu, Aug 7, 2008 at 9:27 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
We can call it whatever version. At this point I do
On Thu, Aug 7, 2008 at 9:27 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> We can call it whatever version. At this point I don't think it much
> matters.
I'd like to see the current trunk moved to a code-named branch, so
that we can make incremental improvements in 2.1, 2.2, 2.3, etc.
In the cu
Yah, it doesn't need to be complete to talk about it. It's just highly
useful for people to understand the motivation, and to dig in if they
see fit and to do that they need to understand the mechanics of the
system.
On 7-Aug-08, at 10:06 AM, Oleg Gusakov wrote:
Jason van Zyl wrote:
I've
Jason van Zyl wrote:
I've asked Oleg do document the architecture in Mercury
Doing. May take several days as there is a lot to cover and I have to
joggle this activity with the rest.
Thanks,
Oleg
-
To unsubscribe, e-mail
On 7-Aug-08, at 9:21 AM, Brett Porter wrote:
On 08/08/2008, at 1:04 AM, Jason van Zyl wrote:
We should be focusing on the release candidate in the short term.
Of course.
As far as 2.1 discussions so productive discussion will happen 1)
unless people have the necessary background, and 2)
On 7-Aug-08, at 9:07 AM, John Casey wrote:
I think that to be clear moving forward, the information (and, I
suppose, background) should probably focus on creating a formal,
*written* spec for every major piece - separate ones for lifecycle
management, project building, artifact resolution,
On 08/08/2008, at 1:04 AM, Jason van Zyl wrote:
We should be focusing on the release candidate in the short term.
Of course.
As far as 2.1 discussions so productive discussion will happen 1)
unless people have the necessary background, and 2) are given enough
time to prepare.
That's wh
I think that to be clear moving forward, the information (and, I
suppose, background) should probably focus on creating a formal,
*written* spec for every major piece - separate ones for lifecycle
management, project building, artifact resolution, etc...*not*
describing what we're currently in
We should be focusing on the release candidate in the short term.
As far as 2.1 discussions so productive discussion will happen 1)
unless people have the necessary background, and 2) are given enough
time to prepare.
I have no time until next week for a couple hour discussion, and
people
I'd love to but I have conflicting meetings.
Ralph
Brett Porter wrote:
anyone else?
On 05/08/2008, at 9:04 AM, John Casey wrote:
I can be there, I think.
Brett Porter wrote:
Hi,
As I shift back to looking at 2.1-alpha-1 regressions in JIRA and
the changes on trunk so far, I was hoping we
On 07/08/2008, at 6:58 PM, Arnaud HERITIER wrote:
Not at 11am (dinner time in france)
Perhaps later in the night
Right, of course... that works for me, I'll be happy to get up later :)
What's a better time?
I'll see who is around maybe an hour or two after that.
Cheers,
Brett
Arnaud
O
Not at 11am (dinner time in france)
Perhaps later in the night
Arnaud
On Thu, Aug 7, 2008 at 10:45 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> anyone else?
>
>
> On 05/08/2008, at 9:04 AM, John Casey wrote:
>
> I can be there, I think.
>>
>> Brett Porter wrote:
>>
>>> Hi,
>>> As I shift back
anyone else?
On 05/08/2008, at 9:04 AM, John Casey wrote:
I can be there, I think.
Brett Porter wrote:
Hi,
As I shift back to looking at 2.1-alpha-1 regressions in JIRA and
the changes on trunk so far, I was hoping we could have a once off
meeting in IRC to gather up who's working on what
I can be there, I think.
Brett Porter wrote:
Hi,
As I shift back to looking at 2.1-alpha-1 regressions in JIRA and the
changes on trunk so far, I was hoping we could have a once off meeting
in IRC to gather up who's working on what, where we are going next, and
where we stand for a release.
Hi,
As I shift back to looking at 2.1-alpha-1 regressions in JIRA and the
changes on trunk so far, I was hoping we could have a once off meeting
in IRC to gather up who's working on what, where we are going next,
and where we stand for a release. I don't want to waste a bunch of
time work
38 matches
Mail list logo
