maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <>
Subject RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
Date Sat, 03 Dec 2011 17:32:06 GMT
Please change subject as it's not related to the vote thread.

2011/12/3 Brian Fox <>:
> The RCs were started for a very specific reason, to improve the
> quality of our releases. Just breezing through this thread, there are
> clearly issues with memory and some other stuff here that may be

Most of projects I have tested doesn't show that (and believe me I
have tested a lot sure not releasing on a ngnix server :-) ).

But If I correctly read those mails
( or, I don't see sometimes
related with this candidate for release build.

Quoted: "The dedicated build server is of arch amd64 and as it turned out, the
PermGen space consumption on that arch is even worse. Even with 256m PermGen
space the build stops with an "OOME: PermGen space" after 45 of 417
projects. However, M303 and M304 behave *exactly* the same (multiple runs
for each). Even for M221 the build stops now after 55 projects (but
different build order compared to M30x).

So the good news: No regression with M304. The bad news: Something consumes
PermGen space meanwhile really fast. It might be as well one of the plugins
that have been updated in the last 3 of 4 months :-/

Sorry maybe as I'm not a native english reader, I misunderstand something.

> bigger than we understand in this small testing surface. An RC build
> will get more eyes and either confirm these aren't a big deal, or they
> are.
> Reminder of where we were with 2.0.7, 2.0.8 and why we do RCs:
> I'm -1 on a release without some RCs.
As your mail is in the release vote does this -1 apply on the release ?

Again I start a release process and produce a "candidate for release"
build with a naming 3.0.4 for 5 days vote.
Something failed, so it has been fixed and I restarted a vote with a
second "candidate for release" called 3.0.4 for 5 days vote.
(retagging etc.... )

What is the difference with producing something called RC1 (build
which will never published) and rebuild after some days the SAME thing
without the RC end naming ?

Sorry but except some marketing naming I don't see any difference in a
technical point of view (everything can be tracked in the scm).

*Again* as already said I don't have any issues using this rc mode, if
this vote fail, I will use it.

Olivier hacker not marketer :-)

> On Thu, Dec 1, 2011 at 3:17 PM, John Casey <> wrote:
>> On 12/1/11 10:27 AM, Olivier Lamy wrote:
>>> 2011/12/1 Jörg Schaible<>:
>>>> Benjamin Bentmann wrote:
>>>>> Olivier Lamy wrote:
>>>>>> I'd like to release Apache Maven 3.0.4 (take 2).
>>>>>> [...]
>>>>>> Note the difference with first vote is an upgrade of aether to 1.13.1
>>>>> What about the memory issue that Jörg brought up? Shouldn't we at least
>>>>> understand the cause and potential impact on other users before
>>>>> continuing the release?
>>>> Continue, I'll report later, but it seems that there's no regression in
>>>> 304
>>>> vs 303.
>>> Thanks!
>>> @Benjamin: I tend to say we must release it (maybe the famous "early
>>> and often' :-) ).
>> Early-and-often is great, but it's not an excuse to be lax on quality
>> standards. Hudson had some famously horrible releases early on, and I
>> suspect they had to do with sacrificing concerns about quality on the altar
>> of early-and-often.
>> An RC would take less than a week more if the code really is ready to go. If
>> it's not, then we don't want to release it, do we?
>>> My goal is to provide a release point (stable tagged build) to get
>>> feedbacks.
>>> Trying to reach/wait the "perfect release" without those feedbacks is
>>> IMHO impossible.
>> Actually it's not; the feedback comes by way of RCs. This is why it's so
>> important to do RCs for Maven core. Maybe we can skip the RC process on
>> plugins (I tend to think a single, quick RC is still a good idea there), but
>> the core is far, far more complex. Even with a huge IT set we cannot hope to
>> cover all use cases there, so it's simply not enough.
>> If Jörg's issue doesn't pop up in this staged release, then I'd say let's
>> just learn that lesson for next time. It takes a little longer using RCs,
>> but it's the ONLY way we've been able to produce releases that weren't
>> riddled with regressions in the past. Even with a strong IT suite, it's
>> still good practice.
>> As an aside, we might as well call this staging of 3.0.4 a RC and discuss it
>> here as if it was. The main difference is procedural IMO, in that this is a
>> [VOTE] thread, not a [DISCUSS] thread about whether the staged RC is ready
>> to go. IMO that's an important distinction, since the 72h time limit is
>> lurking nearby, but we'd still want to time-box the review of any RC
>>> The previous "issue" for ngnix users was blocker as some oss forge use
>>> it. So I cancel it and restart one (and thanks for the fast aether
>>> change).
>>> But for such memory issue at least users can change MAVEN_OPTS.
>>> My email [1] to Jörg describe various things to test on his private
>>> company build (I hope he will have time to provide such feedbacks with
>>> a stable maven build)
>>>> Cheers,
>>>> Jörg
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>> --
>> John Casey
>> Developer, PMC Chair - Apache Maven (
>> Blog:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message