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 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: http://www.sonatype.com/people/2008/04/quality-is-not-accidental/ I'm -1 on a release without some RCs. On Thu, Dec 1, 2011 at 3:17 PM, John Casey <jdca...@commonjava.org> wrote: > On 12/1/11 10:27 AM, Olivier Lamy wrote: >> >> 2011/12/1 Jörg Schaible<joerg.schai...@scalaris.com>: >>> >>> 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: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> > > > -- > John Casey > Developer, PMC Chair - Apache Maven (http://maven.apache.org) > Blog: http://www.johnofalltrades.name/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
