2012/11/26 Stephen Connolly <stephen.alan.conno...@gmail.com>: > Well technically we only vote on the sources *not* the binaries *nor* the
You don't test the binaries we will propose to users for download ? Do you think users download sources to build maven locally ? So for me binaries we produce as important as sources as long as it's material we propose to users. > SCM tag... We just have tge habit if giving the tag for good form... With > the move to GIT, I don't see it as Bering so critical... You can always > include the tag hash ID in the vote email and reproducibility isn't so > important when we have the sources... Build ability of the sources is one > if the criteria we are supposed to check before voting That's not my point ! Please do not mix release process and the tool we use for sources. My point is to have a separate branch for the release manager to not prevent others to commit in trunk. > > On Monday, 26 November 2012, Olivier Lamy wrote: > >> 2012/11/25 Jason van Zyl <ja...@tesla.io <javascript:;>>: >> > >> > On Nov 25, 2012, at 2:07 PM, Brett Porter <br...@apache.org<javascript:;>> >> wrote: >> > >> >> >> >> On 26/11/2012, at 6:42 AM, Jason van Zyl <ja...@tesla.io <javascript:;>> >> wrote: >> >> >> >>> I wish RCs were useful, but I don't believe anyone really looks or >> takes the time to even try anything until it's actually released. >> >> >> >> 3.0.4 had 5 RCs from memory, and so far, 3.1.0 has had one pulled back >> - seems like they are being useful? >> >> >> > >> > I doubt a user would have found that. For issues akin to what Anders >> noticed we can just leave it in staging for a week or two. I think people >> see RC and think "I'll just let everyone else try it." >> > >> >> I don't mind naming them all 3.1.0 and having the RM delete the tag, >> but we should keep enough time/repeats in there to find issues - we don't >> want another "don't use 2.2.0, it's broken" type scenario. >> >> >> > >> > That's easy enough. I'll just leave it in staging, but the crux of the >> argument is in staging or calling it an RC fields no real use from >> non-developers. >> > >> >> Perso what I like with rc mode (or call release branch mode) is the >> idea about having a separate branch for the rm to release. As it >> others can continue hacking in trunk. >> (minor detail: rc naming mode can prevent having to cleanup artifacts >> from various repo manager chain we are using) >> >> Furthermore we usually vote too on sources tarball and some binaries >> distributions (zip/tar.gz) and users will download those files from >> Apache distribution download sites. >> Note there is a process described here >> (http://maven.apache.org/developers/release/maven-core-release.html) >> for that. >> So please include those files in your vote call. >> >> >> >> - Brett >> >> >> >> -- >> >> Brett Porter >> >> br...@apache.org <javascript:;> >> >> http://brettporter.wordpress.com/ >> >> http://au.linkedin.com/in/brettporter >> >> http://twitter.com/brettporter >> >> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> >> >> For additional commands, e-mail: dev-h...@maven.apache.org<javascript:;> >> >> >> > >> > Thanks, >> > >> > Jason >> > >> > ---------------------------------------------------------- >> > Jason van Zyl >> > Founder & CTO, Sonatype >> > Founder, Apache Maven >> > http://twitter.com/jvanzyl >> > --------------------------------------------------------- >> > >> > Selfish deeds are the shortest path to self destruction. >> > >> > -- The Seven Samuari, Akira Kurosawa >> > >> > >> > >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> >> For additional commands, e-mail: dev-h...@maven.apache.org <javascript:;> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
