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
