Re: [VOTE] Release Apache Portals Pluto 3.0.1
Neil Griffin <[email protected]>
| Newsgroups | gmane.comp.jakarta.pluto.devel,gmane.comp.jakarta.pluto.user |
|---|---|
| Message-ID | <[email protected]> |
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
>>>>
>>>>
>>>
>