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
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 the mediator exists we're a lo
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
On 10-Aug-08, at 5:26 PM, Ralph Goers wrote:
Jason van Zyl wrote:
The other issues identify a problem that is a little harder to fix
only because I haven't figured out how it could be done without
being incompatible, even if what is currently happening -
deploying poms with a variable
Jason van Zyl wrote:
The other issues identify a problem that is a little harder to fix
only because I haven't figured out how it could be done without being
incompatible, even if what is currently happening - deploying poms
with a variable in the version element - is just wrong.
Not neces
On 10-Aug-08, at 2:25 PM, Ralph Goers wrote:
That is all OK, but I'd really like to see a 2.1 that allows more to
be done on the 2.0.x branch than we are currently comfortable with.
That's the plan that people have been suggesting and what I refer to
as the intermediary bridge i.e. the nex
That is all OK, but I'd really like to see a 2.1 that allows more to be
done on the 2.0.x branch than we are currently comfortable with. Nothing
as revolutionary as what is in trunk, but with some ability to fix some
problems that might not be completely compatible. The bugs I am
currently look
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
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: Thursday, August 07, 2008 11:16 PM
To: Maven Developers List
Subject: Re: Versioning Maven (was: Re: Maven 2.1
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
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 toward larger feature introdu
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
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,
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
[EMAIL PROTECTED] wrote:
+this.artifact = new DefaultArtifactFactory().cloneArtifact(
project.artifact );
This doesn't seem very component-oriented :)
Maybe clone should be a method of artifact (not using the standard Java
one, but createCopy() or something). The clone method doesn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+1
Brett Porter wrote:
| This would be pointless - the version in /lib is used, so depending on a
| newer version of maven-project won't help the clover plugin on 2.0.
|
| I'd say do it properly in maven-artifact/project, and put the hackish
| soluti
This would be pointless - the version in /lib is used, so depending on a
newer version of maven-project won't help the clover plugin on 2.0.
I'd say do it properly in maven-artifact/project, and put the hackish
solution in clover plugin.
- Brett
John Casey wrote:
-BEGIN PGP SIGNED MESSA
ifact/src/main/java/org/apache/maven/artifact/factory/ maven-
| |>artifact/src/main/java/org/apache/maven/artifact/versioning/ maven-
| |>project/src/main/java/org/apache/maven/project/
| |>
| |>Author: jdcasey
| |>Date: Tue Nov 1 07:55:45 2005
| |>New Revision: 330080
| |>
| |&g
t/src/main/java/org/apache/maven/artifact/versioning/ maven-
|>project/src/main/java/org/apache/maven/project/
|>
|>Author: jdcasey
|>Date: Tue Nov 1 07:55:45 2005
|>New Revision: 330080
|>
|>URL: http://svn.apache.org/viewcvs?rev=330080&view=rev
|>Log:
|>PR: MNG-133
maven-
> artifact/src/main/java/org/apache/maven/artifact/versioning/ maven-
> project/src/main/java/org/apache/maven/project/
>
> Author: jdcasey
> Date: Tue Nov 1 07:55:45 2005
> New Revision: 330080
>
> URL: http://svn.apache.org/viewcvs?rev=330080
Author: brett
Date: Tue Jul 19 01:23:01 2005
New Revision: 219630
URL: http://svn.apache.org/viewcvs?rev=219630&view=rev
Log:
PR: MNG-505
use comparable versions in ranges
Modified:
maven/components/trunk/maven-artifact-ant/src/main/java/org/apache/maven/artifact/ant/DependenciesTask.java
33 matches
Mail list logo
