Re: 3.1.0 Site
Hi Jason, Ok, I'll do it tonight. Regards, Hervé Le vendredi 28 juin 2013 14:12:34 Jason van Zyl a écrit : Hervé, Can you please stage the site for 3.1.0? I'm going to put 3.1.0 up for vote. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release process updates
Hello, I think svn/git are most interesting, as AFAIK all core-plugins reside in these SCMs :-).[1] Being able to easily review the code diff between several takes or releases has a value of it's own IMO. With websvn, gitweb or github e.g., it is quite trivial to create a link which shows the complete diff/patch between two tags/branches. To include such a link in the vote mail would be great (fisheye/viewcvs do *not* have this ability unfortunately), at least a command line reproducing the patch could help. It is much more effort, when every reviewer does this work on her own, let alone when tags are mutable as they are in the current process, where you have to scan the log for the correct revisions/hashes. Regards Mirko [1] People still forced to use CVS or Sourcesafe should probably just look for a new job or when they are the ones responsible for this a good shrink ;-). -- Sent from my mobile On Jun 29, 2013 3:30 AM, Chris Graham chrisgw...@gmail.com wrote: Moreover, the discussion is very SVN/GIT centric. The release plugin and continuum (as far as I know) are the primary users of the SCM api. The entire scm api is an abstraction layer that is very cvs/svn centric (for historical reasons) but an abstraction layer all the same, and abstraction layers tend to the lowest common denominator (they have too). So as the Do we respin version nos/tags thread summarized, what is good practice for one may not be for another. So, just like life, it's full of comprimises. If we included AccuRev, ClearCase and Jazz, for example, into this thread, then we'd have (probably) an entirely different view, based around what those SCM's either could or could not do. (For example, Jazz can not delete it's tags from the cli, only from the full Eclipse GUI or Web clients - so that it not automatable. But the svn provider does not delete tags either, so there may always be some manual cleanup involved). As it stands, I don't see the need to include the rev no in the email, as the tag that has been created, that we are voting on, has it's own revision no, and is easily found, as is the path. If the vote fails, the necessary changes are made, the same tag, with a different revision no is used. If the vote passes, the tag remains permanent. I see little value in documenting the failed releases. You will always be able to trawl through these email lists and svn history to retreive the intermediate details, should you ever need them. -Chris On Fri, Jun 28, 2013 at 10:21 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Friday, 28 June 2013, Fred Cooke wrote: For git the unique hash is sufficient, you don't really need the tag at all, they simply point to the unique hash (or another tag, in a chain). If Git was the SCM of choice, I'd use RCX tags, and then not retag for final, but rather point the final tag AT the last, accepted RC tag. For example artifact-RC1 1234567890ABCDE artifact-RC2 ABCDE1234567890 artifact-RC3 12345ABCDE67890 artifact artifact-RC3 (yes this is possible! and is correctly resolved to the hash pointed to by the final chain-link) And how exactly do we bake the hash into the Pom? We need to know what we are baking into the Pom *before* we can commit the Pom So in the GIT world, we need to bake a tag into the Pom as we cannot predict the hash. In the Subversion world, we need to bake a tag without revision into the Pom as we cannot predict the revision we will get when we do commit. I am fine with saying for GIT *votes* the hash of the tag should be included in the vote email, but pushing the tag at the time of the vote I see as a bad plan (unless we decide to change the tag naming convention) Subversion does not let us avoid committing the tag, so in that case I am fine with saying in the vote email tag@1234342 But I don't see (given the way the version numbering vote went) why we need to do anything other than the above 1 small change to the vote emails And keep in mind that given that SCM is just a convenience, even that is not strictly necessary... It is the -src.tar.gz that we are voting on... Everything else is just a convenience If I were forced (at gun point) to use SVN again, I'd not create real SVN-tags, I'd modify my tooling to either add SVN meta data linking name and revision number and path or do the same in a plain text file(s) somewhere in the repo. The entire SVN cp thing leaves me feeling ill. SVN mv makes me want to cry like a girl. From the help info: Note: this subcommand is equivalent to a 'copy' and 'delete'. If only file systems were this good! :-p In terms of current SVN usage, the SVN mv command is probably a good choice, as already discussed. You could argue that a cp would be better, but this creates wholesale duplication, which is never good. Fred. On Fri,
Re: [VOTE] Release Maven Enforcer version 1.3 (take 2)
Hi Sebb, none of these files will end up in Maven Central, they are all used for tests. For me that's not enough reason to cancel the vote. thanks, Robert Op Thu, 27 Jun 2013 12:26:03 +0200 schreef sebb seb...@gmail.com: On 25 June 2013 21:23, Robert Scholte rfscho...@apache.org wrote: Hi, We solved 15 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=19011 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11530status=1 Staging repo: https://repository.apache.org/content/repositories/maven-070/ https://repository.apache.org/content/repositories/maven-070/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip Staging site: http://maven.apache.org/enforcer-archives/enforcer-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [X] -1 There are lots of files in the source archive that don't have AL headers: enforcer-1.3/DEPENDENCIES enforcer-1.3/enforcer-api/src/custom-rule-sample/pom.xml enforcer-1.3/enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer/rule/MyCustomRule.java enforcer-1.3/enforcer-api/src/custom-rule-sample/src/usage-pom.xml enforcer-1.3/enforcer-api/src/custom-rule-sample/usage-pom.xml enforcer-1.3/enforcer-api/src/main/assembly/custom-rule-sample.xml enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/no-repositories/child/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/no-repositories/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-plugin-repositories/child/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-plugin-repositories/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-repositories/child/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-repositories/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-plugin-repositories/child/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-plugin-repositories/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-repositories/child/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-repositories/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/checkPluginPropertyVersion/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/checkPluginVersionProfile/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/getPomRecursively/b/c/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/getPomRecursively/b/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/getPomRecursively/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentExpression/child/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentExpression/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentRelativePathDirectory/parent/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentRelativePathDirectory/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentRelativePath/parent/pom.xml enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentRelativePath/pom.xml enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer126_maven-plugin-1.0.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer128_api-1.4.0.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer128_api-1.5.0.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer128_api-1.6.0.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer128_classic-0.9.9.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer134_model-1.0-20130423.042904-7222.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer134_model-1.0-20130423.044324-5638.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer134_modelbuilder-1.0-SNAPSHOT.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer134_project-1.0-SNAPSHOT.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_archiver-2.1.1.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_classworlds-1.1-alpha-2.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_container-default-1.0-alpha-9-stable-1.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_io-2.0.3.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_utils-1.0.4.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_utils-3.0.pom
[RESULT] [VOTE] Release Maven Enforcer version 1.3 (take 2)
Hi, The vote has passed with the following result: +1 (binding): Olivier Lamy, Hervé BOUTEMY, Robert Scholte +1 (non binding): Tony Chemit I will promote the artifacts to the central repo. Op Tue, 25 Jun 2013 22:23:13 +0200 schreef Robert Scholte rfscho...@apache.org: Hi, We solved 15 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=19011 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11530status=1 Staging repo: https://repository.apache.org/content/repositories/maven-070/ https://repository.apache.org/content/repositories/maven-070/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip Staging site: http://maven.apache.org/enforcer-archives/enforcer-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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
Donay
Hi, recently I noticed a new thing at the Jira of Codehaus: Donay It is saying Facing this issue? Let the Developers help you out. Here Donay explains how it works: https://secure.donay.com/site/how-it-works Has this been shared with the community? Does anybody have experience with this? IIRC we had a similar situation with http://www.freedomsponsors.org/ and we've removed their comments if they were actively busy with crowdfunding. Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.1.0 Site
Great, thanks. I'll push out the vote tomorrow. On Jun 29, 2013, at 2:07 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi Jason, Ok, I'll do it tonight. Regards, Hervé Le vendredi 28 juin 2013 14:12:34 Jason van Zyl a écrit : Hervé, Can you please stage the site for 3.1.0? I'm going to put 3.1.0 up for vote. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Re: 3.1.0 Site
site published http://maven.apache.org/ref/3.1.0/ Regards, Hervé Le samedi 29 juin 2013 11:15:27 Jason van Zyl a écrit : Great, thanks. I'll push out the vote tomorrow. On Jun 29, 2013, at 2:07 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi Jason, Ok, I'll do it tonight. Regards, Hervé Le vendredi 28 juin 2013 14:12:34 Jason van Zyl a écrit : Hervé, Can you please stage the site for 3.1.0? I'm going to put 3.1.0 up for vote. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
