On May 14, 2012, at 5:35 PM, Sergiu Dumitriu wrote: > On 05/14/2012 11:17 AM, Vincent Massol wrote: >> >> On May 14, 2012, at 5:00 PM, Sergiu Dumitriu wrote: >> >>> On 05/14/2012 03:40 AM, Caleb James DeLisle wrote: >>>> >>>> >>>> On 05/14/2012 02:56 AM, Vincent Massol wrote: >>>>> Hi Caleb, >>>>> >>>>> On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'd like to change the<repository> in each top level pom to nexus so >>>>>> that on release, all releases will go directly to staging by default. >>>>>> Agent1 already has an account in the staging repository from my last >>>>>> release so this should just work. >>>>>> >>>>>> WDYT? >>>>> >>>>> +1 for using staging but not to change the target repo. We need to be >>>>> able to go from staging to target. >>>>> The canonical way is to use mvn release:stage. >>>> >>>> I don't know if it's as much canonical as it is the way that maven offers. >>>> Nexus has a user interface which allows you to promote a release out of >>>> staging with just a few clicks. >>>> I think maven's release:stage was designed with the assumption that most >>>> people don't have this luxury. >>>> >>>> My concern with leaving a live repository in the pom file is that it seems >>>> to be just asking for an accident >>>> where everything gets pushed to the live server and has to be weeded out >>>> manually. I would like to avoid this if at all possible. >>>> I want to minimize the risk and the best way I know to do that is to not >>>> let maven know where scp://maven.xwiki is. >>>> >>>> Caleb >>> >>> Well, re-releasing will take care of the "bad" artifacts, since as long as >>> they have the same version, uploading will override the older ones with the >>> new ones. The only risk is people downloading the bad artifacts between >>> release attempts. >> >> This is not fully correct. In the meantime any number of users could have >> use that remote repo and have the artifacts locally. Then they may report >> errors in our jira saying they're using that version of XE and we wouldn't >> be able to understand nor reproduce the issue for example. >> >> It's very bad andit should not be allowed (except under very special >> circumstances) to re-release in a remote repository. It's completely >> forbidden for ex in the Maven Central repo. >> >> So a big -1 to re-release in our remote repo as a rule. Which is why I agree >> with Caleb about staging. > > I agree. To be clear, I wasn't proposing to skip staging, I was just arguing > that it's not very hard to clean up a bad release. > > Still, a public staging repo can have the same effect: much too eager people > could just download from the staging repo instead of the release repo. It's > the user's decision to download an unannounced release. Our official > downloads are from OW2, the maven repositories are supposed to be used only > by developers. That's not true in general, though, and a good counter-example > is the maven central repo which for some projects is the only download > location, and which some users (and tools) check directly for new versions > instead of checking the project's website.
It's not true for extensions too. And that's going to be pretty heavily used with the EM usage growing up. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
