On Sat, 12 Jul 2008 09:10:03 John Casey wrote:
> I think if we're going to try to take a hard line on maintaining a
> public API, then we need to define that API in a separate artifact
> that we can place strict limits on.
thats a great idea
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL P
On Jul 11, 2008, at 2:38 PM, Dennis Lundberg wrote:
John Casey wrote:
Looking at the Clirr violations, it seems that the problem is a
change in the number of parameters to various method in the
generated parser classes:
[ERROR]
org.apache.maven.artifact.repository.metadata.io.xpp3.Metadat
John Casey wrote:
Looking at the Clirr violations, it seems that the problem is a change
in the number of parameters to various method in the generated parser
classes:
[ERROR]
org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader:
In method 'public boolean getBooleanValue(
Looking at the Clirr violations, it seems that the problem is a change
in the number of parameters to various method in the generated parser
classes:
[ERROR]
org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader:
In method 'public boolean getBooleanValue(java.lang.String,
-Original Message-
From: Dennis Lundberg [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2008 11:57 AM
To: Maven Developers List
Subject: Re: Preparing for 2.0.10 RC1
Brian, I was planning to upgrade the dependency on Modello in the core,
because of a binary incompatibility [1] [2]. I was
Brian, I was planning to upgrade the dependency on Modello in the core,
because of a binary incompatibility [1] [2]. I was waiting for the build
to fail in CI before I fixed it, but it doesn't seem to have failed yet.
The change I was going to make would fix the Modello issue that you
document
: Preparing for 2.0.10 RC1
I was thinking the same thing the other day. I think this is a good
idea.
-john
Arnaud HERITIER wrote:
In the process couldn't we create a 2.0.10-RC branch where we fix
issues
discovered in RCs.
At the end we create the final release from this branch a
Sure, we can do that.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 10, 2008 1:55 PM
To: Maven Developers List
Subject: Re: Preparing for 2.0.10 RC1
I was thinking the same thing the other day. I think this is a good
idea.
-john
Arnaud HERITIER
I was thinking the same thing the other day. I think this is a good idea.
-john
Arnaud HERITIER wrote:
In the process couldn't we create a 2.0.10-RC branch where we fix issues
discovered in RCs.
At the end we create the final release from this branch and we merge changes
in the 2.0.x trunk.
We
In the process couldn't we create a 2.0.10-RC branch where we fix issues
discovered in RCs.
At the end we create the final release from this branch and we merge changes
in the 2.0.x trunk.
We that we are sure that no other commit on 2.0.x can be added by error in
the RC process.
(it's just a propo
>> 1) we will stop to fix any regressions between 2.0.9 and 2.0.10
>What's the rationale for this?
I meant stop the current RC to fix the issue and then recut the next RC. We
won't respin for other random issues.
I think what he intended to say is we're going to do a code freeze and
only fix regressions that are exposed by testing of the RCs.
-john
Jochen Wiedmann wrote:
On Thu, Jul 10, 2008 at 5:14 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
1) we will stop to fix any regressions between 2.0
On Thu, Jul 10, 2008 at 5:14 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> 1) we will stop to fix any regressions between 2.0.9 and 2.0.10
What's the rationale for this?
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief
13 matches
Mail list logo
