2013/6/26 sebb <seb...@gmail.com>: > It would be a lot better to use RC1 RC2 etc initially, and copy the > successful tag to the GA tag. > this mean modifying manually the pom to change version (from 1.0-RC1 to 1.0) before copying teh RC tag, changing the scm information etc... Rebuild jars ? because if you change the pom it means you change the sources so need an other build/vote..
Frankly currently we have a very simple process which works very fine: * mvn clean release:prepare release:perform -B (-Dusername= -Dpassword=) * verifying staging repo * closing the staging repo * cd target/checkout && mvn clean site-deploy * and that's it Perso, I don't want we move to something over complicated without any real added value. > On 25 June 2013 19:38, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed >> release vote instead of deleting them. >> >> >> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: >> >>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers >>> <ralph.go...@dslextreme.com>wrote: >>> >>>> Again I have to disagree. The release manager will send an email closing >>>> the prior release. At this point all the prior release artifacts are junk >>>> even if they still exist. At some point the release manager will delete >>>> the tag and rerun the release. >>> >>> >>> That's a no-no IMO. Tags that have been voted on should never be deleted. >>> >>> Gary >>> >>> >>> >>>> At this point the tag is still junk to everyone else because they have no >>>> idea what the RM is doing - so they shouldn't be making assumptions about >>>> non-released tags. Once he sends the email though the tag will be valid. >>>> Sure having the revision number helps but unless the RM completely screws >>>> up the tag should be sufficient. >>>> >>>> Ralph >>>> >>>> >>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: >>>> >>>>> Not really, no. The developer may have re-spun it again and be about to >>>>> email again. You have no idea what you're looking at unless you know the >>>>> revision. SVN will die off within a decade and this discussion will >>>> become >>>>> critical. Better to figure out how to support proper techniques now, >>>> rather >>>>> than wait until forced to. >>>>> >>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ralph.go...@dslextreme.com >>>>> wrote: >>>>> >>>>>> I disagree that the revision is required. I know that the RM is going >>>> to >>>>>> recreate the tag with each release candidate. Therefore, so long as I >>>>>> refetch that tag for every release vote I can be confident that I am >>>>>> reviewing the release contents. >>>>>> >>>>>> Ralph >>>>>> >>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote: >>>>>> >>>>>>> The mission of the ASF is to release software as source, and to ensure >>>>>>> that the released source is available under the Apache Licence. >>>>>>> >>>>>>> Before a release can be approved it must be voted on by the PMC. >>>>>>> The review process needs to establish that the proposed source release >>>>>>> meets those aims. >>>>>>> >>>>>>> It's all but impossible for reviewers to examine every single file in >>>>>>> a source archive to determine if it meets the criteria. >>>>>>> And it's not unknown for spurious files to creep into a release >>>>>>> (perhaps from a stale workspace - are releases always built from a >>>>>>> fresh checkout of the tag?) >>>>>>> >>>>>>> However, PMCs are also required to check what is added to the SCM >>>>>>> (SVN/Git) to make sure it meets the required license criteria. >>>>>>> This is done on an ongoing basis as part of reviewing check-ins and >>>>>>> accepting new contributions. >>>>>>> So provided that all the files in the source release are also present >>>>>>> in SCM, the PMC can be reasonably sure that the source release meets >>>>>>> the ASF criteria. >>>>>>> >>>>>>> Without having the SCM as a database of validated files, there are far >>>>>>> too many files in the average source archive to check individually. >>>>>>> And how would one check their provenance? The obvious way is to >>>>>>> compare them with the entries in SCM. >>>>>>> >>>>>>> Therefore, I contend that a release vote does not make sense without >>>>>>> the SCM tag. >>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail also >>>>>>> needs the revision. >>>>>>> >>>>>>> Whether every reviewer actually checks the source archive against SCM >>>>>>> is another matter. >>>>>>> But if the required SCM information is not present, it would be >>>>>>> difficult to argue that the RM had provided sufficient information for >>>>>>> a valid review to take place. >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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 >>>>>> >>>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second >>> Edition<http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >> >> >> --------------------------------------------------------------------- >> 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 > -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
