On 19 December 2011 19:10, Phil Steitz <phil.ste...@gmail.com> wrote: > On 12/19/11 12:02 PM, sebb wrote: >> On 19 December 2011 18:24, Phil Steitz <phil.ste...@gmail.com> wrote: >>> On 12/19/11 11:13 AM, sebb wrote: >>>> This is a minor release to fix a regression in 2.1 >>>> >>>> What's new in 2.1.1 >>>> =================== >>>> Version 2.1.1 is a bugfix release to address a regression in 2.1: >>>> >>>> * JEXL-124: Array parameters to methods don't work anymore >>>> >>>> There are no other changes >>>> >>>> Tag: >>>> >>>> https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1_1-RC1/ >>>> (Last Changed Rev: 1220732) >>>> >>>> Site: >>>> >>>> http://people.apache.org/~sebb/jexl-2.1.1-RC1 >>>> >>>> Binaries: >>> This is a nit - in VOTE threads, we should not label the whole >>> release distribution "binaries." The release includes both source >>> and binary distributions. >> OK, will call them artifacts in future. >> >>> It would also be great if somehow we >>> could get the maven build machine to produce a directory that >>> includes exactly what is going to /dist, which *is* the release. >> The Nexus staging repo I created includes source and binary jars, >> which will end up in the Maven repo, and source and binary archives >> which will end up in /dist >> >> Since we release source to Maven, AIUI we need to vote on both sets of files. >> >> I don't really care if that is done via one staging repo in Nexus, as >> I have done here, or a Nexus staging repo for Maven, and a separate >> staging area for /dist. >> >> However I do care that we vote on both sets of files, and that the >> exact files we vote on are the ones that are released. >> >> AFAIK, it's easy enough to omit the non-Maven files from Nexus: >> >> mvn deploy -Prelease >> >> I used "mvn package deploy -Prelease" specifically to include the >> non-Maven archives. >> >> What I don't know offhand is how to _stage_ the non-Maven artifacts using >> Maven. >> >> So I created the combined staging repo, and had planned to sort out >> the deployment to /dist after the vote. >> >> However, I'm happy to try using separate a staging area for /dist, if >> that's what is needed. >> >> I can just move the /dist files to a separate staging area now, and >> send round a new VOTE with the same files in two different >> directories. > > Not necessary, IMO; just nice to have for the future if we can > figure out how to get the actual release separated out so we can see > what is going to dist/
Basically that's the files that aren't jars or their associated sigs and hashes. I've written a Python script that fetches the zip and tar.gz files from Nexus. As I test I used it to copy them to http://people.apache.org/~sebb/jexl-2.1.1-RC1-dist At present it seems there is no standard process for staging and releasing files to /dist. It would be nice to integrate this into our Maven release process. I raised a JIRA [1] some while ago to see if Nexus could also act as staging repo for /dist, but that has gone round in circles a couple of times and got nowhere. Pity, because Nexus is convenient for Maven staging, and it does much of the work for /dist staging already (checking sigs and hashes, providing a common location for release votes). [1] https://issues.apache.org/jira/browse/INFRA-4144 > Phil >> >>> Phil >>>> https://repository.apache.org/content/repositories/orgapachecommons-368/org/apache/commons/commons-jexl/2.1.1/ >>>> >>>> This vote will be open for at least 72 hours, closing no sooner than: >>>> 20:00PM GMT, Dec 11th. >>>> >>>> [ ] +1 Release these artifacts >>>> [ ] +0 OK, but... >>>> [ ] -0 OK, but really should fix... >>>> [ ] -1 I oppose this release because.. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
