Re: [VOTE] Release Apache Portals Pluto 3.0.1
Neil Griffin <[email protected]> Wed, 16 May 2018 11:48:12 -0400
| Newsgroups | gmane.comp.jakarta.pluto.devel,gmane.comp.jakarta.pluto.user |
|---|---|
| Message-ID | <[email protected]> |
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? 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). 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 > <[email protected]> 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 <[email protected]> wrote: >>>>> >>>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin >>>>> <[email protected]> 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 >>>>>>> <[email protected]> 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 >>>>> <[email protected]> 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 >>>>>>> <[email protected]> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >> >