Hi Neil, On Wed, May 16, 2018 at 5:48 PM, Neil Griffin <neil.grif...@portletfaces.org> wrote: > Hi Woonsan, > > Step 12 is "Release the bundle Zip file" > https://github.com/apache/portals-pluto/blob/master/RELEASE-PROCEDURE.txt#L129-L146 > > And Step 13 is "PUT THE RELEASE CANDIDATE UP FOR A VOTE" > https://github.com/apache/portals-pluto/blob/master/RELEASE-PROCEDURE.txt#L148-L164 > > Q1. I think I need to add a step in between that uploads > pluto-3.0.0-source-release.zip to Nexus. Would you agree?
That's an option. But I don't think it is required to upload the the source-release.zip to Nexus. It could be a convenient, automated option though. The reason why I suggested you upload the source-release.zip to /dist/dev/... folder is because: - assuming the existing build process generates source-release.zip file already (based on the fact that there was 3.0.0 source-release.zip in /dist/releases/... folder before), it could be easier for you just to copy the locally generated source-release.zip to the temporary /dist/dev/... folder for voting purpose. No change to improve the pom; just adding one more manual step for now, which seems easier, quicker to me for now. - An Apache release is basically a source release in /dist/releases/... Binaries or maven artifacts in Nexus are for convenience. Therefore, it is actually good to upload release candidate source artifacts to /dist/dev/portals-pluto-3.0.1/ folder for voting because it is just a matter of copying from the /dist/dev/... folder to /dist/release/ folder in the end as part of "14. Finalize release process" step for instance. Simpler than Nexus directory in a sense in voting and post-voting process. However, if you feel it's easier to upload the source-release.zip file to Nexus and link to that in voting e-mail message, feel free to do so. Fine as long as the source-release.zip is downloadable and verifiable. > > Q2. Is the "dist/dev" step you mentioned necessary? The release instructions > don't mention "dist/dev" -- only "dist/release" in Step 14 (after the vote). I explained it above. I thought it would be more convenient for you as well, but feel free to upload it to Nexus if it's more convenient and add links to those in voting e-mail message. Regards, Woonsan > > Thank you, > > Neil > > > On 5/15/18 3:51 AM, Woonsan Ko wrote: >> >> Hi Neil, >> >> Thank you very much for the elaborated answers. >> >> I think the only thing required as minimum is to upload the >> pluto-3.0.1-source-release.zip and its signature files (.asc, .sha) to >> https://dist.apache.org/repos/dist/dev/portals/pluto/pluto-3.0.1/, and >> put the link to the directory containing the source zip and signature >> files, in the new VOTE e-mail message. >> >> As I see pluto-3.0.0-source-release.zip in the release dist site, it >> contains everything: portlet-api, pluto-portal and maven archetypes. >> Therefore that should be good enough for our release process. >> Please note that the files you upload should be moved to >> https://dist.apache.org/repos/dist/release/portals/ directory after >> voting passed. In that way, we can be sure what's voted for is the >> same as the real release files. >> >> Git tag is secondary in the release process. It can be tampered on my >> machine or on your machine. By uploading the >> pluto-3.0.1-source-release.zip which you built locally to the dist >> folder and verifying that together, we can be sure the release >> artifacts are fine and we can move to the release distribution folder >> as an official release. >> >> In summary, would you be able to cut a new release and upload >> pluto-3.0.x-source-release.zip to the /dev/portals directory? And >> could you include the directory link where we can download from, for >> verification in the next voting message? >> Then I can proceed with verification and cast my vote afterward. >> >> Thanks in advance, >> >> Woonsan >> >> >> On Tue, May 15, 2018 at 12:27 AM, Neil Griffin >> <neil.grif...@portletfaces.org> wrote: >>> >>> Hi Woonsan, >>> >>> I tried adding this to portals-pluto/pom.xml and it didn't work: >>> >>> <profile> >>> <id>apache-release</id> >>> <build> >>> <plugins> >>> <plugin> >>> <groupId>org.apache.maven.plugins</groupId> >>> <artifactId>maven-assembly-plugin</artifactId> >>> <configuration> >>> <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot> >>> </configuration> >>> </plugin> >>> </plugins> >>> </build> >>> </profile> >>> >>> I also tried -DrunOnlyAtExecutionRoot=true on command line and it didn't >>> work. >>> >>> In other words, when I run the release procedure from the top >>> (portals-pluto/) the maven-assembly-plugin will only generate a >>> "source-release" ZIP for pluto-3.0.1-source-release.zip and nothing else. >>> >>> Since that the only source-release ZIP that has been released in the >>> past, >>> shouldn't that be adequate for this 3.0.1 release? >>> >>> Thank you, >>> >>> Neil >>> >>> >>> On 5/14/18 4:51 PM, Neil Griffin wrote: >>>> >>>> >>>> Hi Woonsan, >>>> >>>> Thank you for your efforts to make sure the release process is correct. >>>> >>>> 1) Regarding the "source-release" bundles: >>>> >>>> I *think* I found the problem as to why they are missing -- it is likely >>>> due to the following config of the maven-assembly-plugin in the >>>> apache-16 >>>> parent-most pom descriptor: >>>> >>>> <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot> >>>> >>>> See: >>>> >>>> https://search.maven.org/remotecontent?filepath=org/apache/apache/16/apache-16.pom >>>> >>>> Since we ran the Maven release plugin from the portals-pluto root, none >>>> of >>>> the jars like pluto-container-api.jar, etc. had the companion >>>> "source-release" bundle. >>>> >>>> The reason why the archetypes worked, is because I released them >>>> individually from their respective "root" directories. >>>> >>>> BTW, as far as I can determine, the "source-release" problem is not new. >>>> It has been there for many years. For example, see: >>>> >>>> >>>> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.portals.pluto%22%20AND%20a%3A%22pluto-container-api%22 >>>> >>>> Anyway, I'll fix it before re-releasing. >>>> >>>> 2) Regarding Git, in the 3.0.0 release Scott pushed the 3.0.0 *commits* >>>> for the vote, but _not_ the *tags* until the vote was final. That worked >>>> well because he actually had to roll-back the release. I recommend we do >>>> it >>>> that way again. >>>> >>>> >>>> -- Neil >>>> >>>> On 5/14/18 11:53 AM, Woonsan Ko wrote: >>>>> >>>>> >>>>> By the way, I'm not trying to block the way. ;-) I'm just trying to >>>>> make a right release (process) this time. >>>>> Please let me know if I can help with anything. I'll help to fix the >>>>> (minimal) things to make a release as soon as possible. :-) >>>>> >>>>> Regards, >>>>> >>>>> Woonsan >>>>> >>>>> >>>>> On Mon, May 14, 2018 at 11:39 AM, Woonsan Ko <woon...@apache.org> >>>>> wrote: >>>>>> >>>>>> >>>>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin >>>>>> <neil.grif...@portletfaces.org> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Woonsan, >>>>>>> >>>>>>> We followed the same process as we did for the 3.0.0 release. >>>>>>> >>>>>>> The "building from source" requirement would be accomplished by >>>>>>> building >>>>>>> source from a Git tag. >>>>>> >>>>>> >>>>>> >>>>>> I don't think a Git tag can replace the requirement of a "valid >>>>>> release package". >>>>>> Pluto 3.0.0 release also contains a valid release package: >>>>>> - >>>>>> >>>>>> https://dist.apache.org/repos/dist/release/portals/pluto/pluto-3.0.0-source-release.zip >>>>>> >>>>>> From this voting email, I want to check if the release source >>>>>> package >>>>>> is valid as an Apache release. >>>>>> I cannot find the candidate source package we want to release. There >>>>>> are binary links only in your voting e-mail for the Pluto 3.0.1. >>>>>> What's the point of this voting if I cannot verify the candidate >>>>>> source packages by building, unit-testing, checking signatures, >>>>>> checking license headers, ...? >>>>>> Please give me the links to download all the *source packages* as >>>>>> release candidate this time, which I can build, test, verify things. >>>>>> Otherwise, I cannot proceed. >>>>>> >>>>>>> >>>>>>> However, the Git commits and tags have not been pushed to the Git >>>>>>> repository >>>>>>> yet, because of the following line: >>>>>>> https://github.com/apache/portals-pluto/blob/master/pom.xml#L649 >>>>>>> >>>>>>> This was intentional, because it would allow us to roll back the >>>>>>> release >>>>>>> process if the voting process were to fail. >>>>>> >>>>>> >>>>>> >>>>>> That might be okay, but again please upload the source packages you >>>>>> built and staged somewhere. I cannot verify nor vote against binaries. >>>>>> >>>>>> If possible, I recommend you to upload to >>>>>> https://dist.apache.org/repos/dist/dev/portals/pluto/... for voting, >>>>>> and later move to /release/ folder after voting passed. >>>>>> The source packages for which we vote should become the actual >>>>>> releases in the end if vote passed. Neither files you have locally nor >>>>>> a git tag. >>>>>> >>>>>>> >>>>>>> This approach also mirrors the concept of the "staging" repository >>>>>>> which >>>>>>> will not be released to Maven Central if the voting process were to >>>>>>> fail. >>>>>> >>>>>> >>>>>> >>>>>> Another approach is just to bump up the version to 3.0.2 if 3.0.1 >>>>>> voting failed and so 3.0.1 tag is not for a release. I don't see any >>>>>> problem by having 3.0.1 tag exists as long as it's not published to >>>>>> both maven repository and distribution site. >>>>>> >>>>>>> >>>>>>> I can provide evidence of the tags and git commits in my local Git >>>>>>> repository if that would help. >>>>>> >>>>>> >>>>>> >>>>>> Git commits or local files cannot help in our release voting and >>>>>> process, IMO. >>>>>> It's better and safer to upload all the source packages and let people >>>>>> verify them before casting a vote. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Woonsan >>>>>> >>>>>>> >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Neil >>>>>>> >>>>>>> >>>>>>> On 5/14/18 10:29 AM, Woonsan Ko wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -1 >>>>>>>> >>>>>>>> I couldn't find pluto-3.0.1 tag in >>>>>>>> https://git-wip-us.apache.org/repos/asf/portals-pluto.git. I wonder >>>>>>>> how the release candidate artifacts were made. The master branch's >>>>>>>> version was not bumped up to 3.0.2-SNAPSHOT either. >>>>>>>> Even worse, there's a stopper in the root pom.xml [1]: >>>>>>>> >>>>>>>> <profile> >>>>>>>> <id>liferay</id> >>>>>>>> <dependencyManagement> >>>>>>>> <dependencies> >>>>>>>> <dependency> >>>>>>>> <groupId>com.liferay.portal</groupId> >>>>>>>> >>>>>>>> <artifactId>com.liferay.cdi.bean.portlet.extension</artifactId> >>>>>>>> <version>1.0.0-SNAPSHOT</version> >>>>>>>> </dependency> >>>>>>>> </dependencies> >>>>>>>> </dependencyManagement> >>>>>>>> <repositories> >>>>>>>> <repository> >>>>>>>> <id>liferay-snapshots</id> >>>>>>>> <name>Liferay Snapshots</name> >>>>>>>> >>>>>>>> <url>https://oss.sonatype.org/content/repositories/snapshots</url> >>>>>>>> <releases> >>>>>>>> <enabled>false</enabled> >>>>>>>> </releases> >>>>>>>> <snapshots> >>>>>>>> <enabled>true</enabled> >>>>>>>> </snapshots> >>>>>>>> </repository> >>>>>>>> </repositories> >>>>>>>> </profile> >>>>>>>> >>>>>>>> Releases must not depend on a SNAPSHOT dependency. And the >>>>>>>> com.liferay.cdi.bean.portlet.extension artifact has no clear >>>>>>>> copyright >>>>>>>> notice. So this is not acceptable. >>>>>>>> If the 'liferay' profile is necessary for Liferay specific TCK >>>>>>>> testing, I'd recommend you to move it out to a special documentation >>>>>>>> explaining how to run Liferay specific TCK testing by configuring >>>>>>>> those in user's settings.xml instead, not in the source >>>>>>>> distribution. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Woonsan >>>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>>>> >>>>>>>> https://git-wip-us.apache.org/repos/asf?p=portals-pluto.git;a=blob;f=pom.xml;h=1fb14997be03c4911ce97ebf0826f59f599a2198;hb=HEAD#l739 >>>>>>>> >>>>>>>> >>>>>>>> On Fri, May 11, 2018 at 3:06 PM, Neil Griffin >>>>>>>> <neil.grif...@portletfaces.org> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear Apache Portals Pluto Team and community, >>>>>>>>> >>>>>>>>> I've staged a release candidate for the new Apache Portals Pluto >>>>>>>>> 3.0.1 >>>>>>>>> release. >>>>>>>>> >>>>>>>>> This release candidate includes: >>>>>>>>> >>>>>>>>> * Fully compliant Reference Implementation of the new Portlet 3.0 >>>>>>>>> Specification per JCR-362 >>>>>>>>> https://www.jcp.org/en/jsr/detail?id=362 >>>>>>>>> * Fully completed (and corrected) TCK (Test Compatibility Kit) for >>>>>>>>> Portlet >>>>>>>>> Spec 3.0 >>>>>>>>> * Updated portlet-api with associated Javadoc improvements >>>>>>>>> * General bugfixes >>>>>>>>> * Updated archetypes >>>>>>>>> >>>>>>>>> Please review the release candidate for this project which is >>>>>>>>> spread >>>>>>>>> across the following THREE maven staging repositories: >>>>>>>>> >>>>>>>>> 1) portlet-api and pluto-portal components and dependencies: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1018 >>>>>>>>> >>>>>>>>> 2) pluto+tomcat bundle: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1019 >>>>>>>>> >>>>>>>>> (The bundle can be tested by unzipping it, >>>>>>>>> and running start.sh from the bin directory, >>>>>>>>> then navigating to http://localhost:8080/pluto >>>>>>>>> and login as pluto/pluto.) >>>>>>>>> >>>>>>>>> 3) maven archetypes: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1020 >>>>>>>>> >>>>>>>>> The Release Notes are available here: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10560&version=12338908 >>>>>>>>> >>>>>>>>> The KEYS file to verify the release artifacts signature can be >>>>>>>>> found >>>>>>>>> here: >>>>>>>>> >>>>>>>>> https://dist.apache.org/repos/dist/release/portals/pluto/KEYS >>>>>>>>> >>>>>>>>> Please review the release candidates and vote on releasing Apache >>>>>>>>> Portals >>>>>>>>> Pluto 3.0.1 >>>>>>>>> >>>>>>>>> Seeing as how I am sending this on a Friday, the normal vote of 72 >>>>>>>>> hours >>>>>>>>> seems unreasonable. Therefore I would like to extend the vote to 96 >>>>>>>>> hours. >>>>>>>>> >>>>>>>>> Please cast your vote: >>>>>>>>> >>>>>>>>> [ ] +1 for Release >>>>>>>>> [ ] 0 for Don't care >>>>>>>>> [ ] -1 Don't release (do provide a reason then) >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards to all, >>>>>>>>> >>>>>>>>> Neil >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin >>>>>> <neil.grif...@portletfaces.org> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Woonsan, >>>>>>> >>>>>>> We followed the same process as we did for the 3.0.0 release. >>>>>>> >>>>>>> The "building from source" requirement would be accomplished by >>>>>>> building >>>>>>> source from a Git tag. >>>>>>> >>>>>>> However, the Git commits and tags have not been pushed to the Git >>>>>>> repository >>>>>>> yet, because of the following line: >>>>>>> https://github.com/apache/portals-pluto/blob/master/pom.xml#L649 >>>>>>> >>>>>>> This was intentional, because it would allow us to roll back the >>>>>>> release >>>>>>> process if the voting process were to fail. >>>>>>> >>>>>>> This approach also mirrors the concept of the "staging" repository >>>>>>> which >>>>>>> will not be released to Maven Central if the voting process were to >>>>>>> fail. >>>>>>> >>>>>>> I can provide evidence of the tags and git commits in my local Git >>>>>>> repository if that would help. >>>>>>> >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Neil >>>>>>> >>>>>>> >>>>>>> On 5/14/18 10:29 AM, Woonsan Ko wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -1 >>>>>>>> >>>>>>>> I couldn't find pluto-3.0.1 tag in >>>>>>>> https://git-wip-us.apache.org/repos/asf/portals-pluto.git. I wonder >>>>>>>> how the release candidate artifacts were made. The master branch's >>>>>>>> version was not bumped up to 3.0.2-SNAPSHOT either. >>>>>>>> Even worse, there's a stopper in the root pom.xml [1]: >>>>>>>> >>>>>>>> <profile> >>>>>>>> <id>liferay</id> >>>>>>>> <dependencyManagement> >>>>>>>> <dependencies> >>>>>>>> <dependency> >>>>>>>> <groupId>com.liferay.portal</groupId> >>>>>>>> >>>>>>>> <artifactId>com.liferay.cdi.bean.portlet.extension</artifactId> >>>>>>>> <version>1.0.0-SNAPSHOT</version> >>>>>>>> </dependency> >>>>>>>> </dependencies> >>>>>>>> </dependencyManagement> >>>>>>>> <repositories> >>>>>>>> <repository> >>>>>>>> <id>liferay-snapshots</id> >>>>>>>> <name>Liferay Snapshots</name> >>>>>>>> >>>>>>>> <url>https://oss.sonatype.org/content/repositories/snapshots</url> >>>>>>>> <releases> >>>>>>>> <enabled>false</enabled> >>>>>>>> </releases> >>>>>>>> <snapshots> >>>>>>>> <enabled>true</enabled> >>>>>>>> </snapshots> >>>>>>>> </repository> >>>>>>>> </repositories> >>>>>>>> </profile> >>>>>>>> >>>>>>>> Releases must not depend on a SNAPSHOT dependency. And the >>>>>>>> com.liferay.cdi.bean.portlet.extension artifact has no clear >>>>>>>> copyright >>>>>>>> notice. So this is not acceptable. >>>>>>>> If the 'liferay' profile is necessary for Liferay specific TCK >>>>>>>> testing, I'd recommend you to move it out to a special documentation >>>>>>>> explaining how to run Liferay specific TCK testing by configuring >>>>>>>> those in user's settings.xml instead, not in the source >>>>>>>> distribution. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Woonsan >>>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>>>> >>>>>>>> https://git-wip-us.apache.org/repos/asf?p=portals-pluto.git;a=blob;f=pom.xml;h=1fb14997be03c4911ce97ebf0826f59f599a2198;hb=HEAD#l739 >>>>>>>> >>>>>>>> >>>>>>>> On Fri, May 11, 2018 at 3:06 PM, Neil Griffin >>>>>>>> <neil.grif...@portletfaces.org> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear Apache Portals Pluto Team and community, >>>>>>>>> >>>>>>>>> I've staged a release candidate for the new Apache Portals Pluto >>>>>>>>> 3.0.1 >>>>>>>>> release. >>>>>>>>> >>>>>>>>> This release candidate includes: >>>>>>>>> >>>>>>>>> * Fully compliant Reference Implementation of the new Portlet 3.0 >>>>>>>>> Specification per JCR-362 >>>>>>>>> https://www.jcp.org/en/jsr/detail?id=362 >>>>>>>>> * Fully completed (and corrected) TCK (Test Compatibility Kit) for >>>>>>>>> Portlet >>>>>>>>> Spec 3.0 >>>>>>>>> * Updated portlet-api with associated Javadoc improvements >>>>>>>>> * General bugfixes >>>>>>>>> * Updated archetypes >>>>>>>>> >>>>>>>>> Please review the release candidate for this project which is >>>>>>>>> spread >>>>>>>>> across the following THREE maven staging repositories: >>>>>>>>> >>>>>>>>> 1) portlet-api and pluto-portal components and dependencies: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1018 >>>>>>>>> >>>>>>>>> 2) pluto+tomcat bundle: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1019 >>>>>>>>> >>>>>>>>> (The bundle can be tested by unzipping it, >>>>>>>>> and running start.sh from the bin directory, >>>>>>>>> then navigating to http://localhost:8080/pluto >>>>>>>>> and login as pluto/pluto.) >>>>>>>>> >>>>>>>>> 3) maven archetypes: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1020 >>>>>>>>> >>>>>>>>> The Release Notes are available here: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10560&version=12338908 >>>>>>>>> >>>>>>>>> The KEYS file to verify the release artifacts signature can be >>>>>>>>> found >>>>>>>>> here: >>>>>>>>> >>>>>>>>> https://dist.apache.org/repos/dist/release/portals/pluto/KEYS >>>>>>>>> >>>>>>>>> Please review the release candidates and vote on releasing Apache >>>>>>>>> Portals >>>>>>>>> Pluto 3.0.1 >>>>>>>>> >>>>>>>>> Seeing as how I am sending this on a Friday, the normal vote of 72 >>>>>>>>> hours >>>>>>>>> seems unreasonable. Therefore I would like to extend the vote to 96 >>>>>>>>> hours. >>>>>>>>> >>>>>>>>> Please cast your vote: >>>>>>>>> >>>>>>>>> [ ] +1 for Release >>>>>>>>> [ ] 0 for Don't care >>>>>>>>> [ ] -1 Don't release (do provide a reason then) >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards to all, >>>>>>>>> >>>>>>>>> Neil >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> >
