[
https://issues.apache.org/jira/browse/BEAM-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Luckey updated BEAM-6798:
---------------------------------
Description:
Currently, we use the gradle release plugin in a way probably not matching
plugins own expectations. Some of this was discussed in [1]
After release branch was cut, we call [2]
{noformat}
./gradlew release
{noformat}
Apart from doing some validations, this creates two commits changing version
property
# sets version in gradle.properties to '${RELEASE}-RC${RC_NUM}' (Commit_1)
# sets version in gradle.properties to back to '${RELEASE}-SNAPSHOT' (Commit_2)
Commit_1 will also be tagged as (tag: v${RELEASE}-RC${RC_NUM})
Afterwards, we continue with 'Commit_2' in testing, bundling and publishing.
I.e. looking into source distribution published, this is not the one tagged,
but its successor. This is probably suboptimal.
The release plugins expectations would probably more along the lines to
actually increment next version (either patch, minor or even major) and release
on that Commit_1.
Based on my current understanding, it seems easier to either
* drop usage of gradle release plugin and just fall back to a plain 'exec git
tag'
* use a beam-release task which depends on gradle release checks, but does no
version changes nor commits
The former has the drawback to also drop the checks done by release plugin, e.g.
* checkCommitNeeded
* checkUpdateNeeded
* checkSnapshotDependencies
* runBuildTasks
* createReleaseTag
which might be still valuable.
[1]
[https://lists.apache.org/thread.html/205472bdaf3c2c5876533750d417c19b0d1078131a3dc04916082ce8@%3Cdev.beam.apache.org%3E]
[2]
[https://github.com/apache/beam/blob/master/release/src/main/scripts/build_release_candidate.sh#L92-L94]
was:
Currently, we use the gradle release plugin in a way probably not matching
plugins own expectations. Some of this was discussed in [1]
After release branch was cut, we call [2]
{noformat}
./gradlew release
{noformat}
Apart from doing some validations, this creates to commits changing version
property
# sets version in gradle.properties to '${RELEASE}-RC${RC_NUM}' (Commit_1)
# sets version in gradle.properties to back to '${RELEASE}-SNAPSHOT' (Commit_2)
Commit_1 will also be tagged as (tag: v${RELEASE}-RC${RC_NUM})
Afterwards, we continue with 'Commit_2' in testing, bundling and publishing.
I.e. looking into source distribution published, this is not the one tagged,
but its successor. This is probably suboptimal.
The release plugins expectations would probably more along the lines to
actually increment next version (either patch, minor or even major) and release
on that Commit_1.
Based on my current understanding, it seems easier to either
* drop usage of gradle release plugin and just fall back to a plain 'exec git
tag'
* use a beam-release task which depends on gradle release checks, but does no
version changes nor commits
The former has the drawback to also drop the checks done by release plugin, e.g.
* checkCommitNeeded
* checkUpdateNeeded
* checkSnapshotDependencies
* runBuildTasks
* createReleaseTag
which might be still valuable.
[1]
https://lists.apache.org/thread.html/205472bdaf3c2c5876533750d417c19b0d1078131a3dc04916082ce8@%3Cdev.beam.apache.org%3E
[2]
https://github.com/apache/beam/blob/master/release/src/main/scripts/build_release_candidate.sh#L92-L94
> Reconsider usage of gradle release plugin
> -----------------------------------------
>
> Key: BEAM-6798
> URL: https://issues.apache.org/jira/browse/BEAM-6798
> Project: Beam
> Issue Type: Improvement
> Components: build-system
> Reporter: Michael Luckey
> Priority: Major
>
> Currently, we use the gradle release plugin in a way probably not matching
> plugins own expectations. Some of this was discussed in [1]
> After release branch was cut, we call [2]
> {noformat}
> ./gradlew release
> {noformat}
> Apart from doing some validations, this creates two commits changing version
> property
> # sets version in gradle.properties to '${RELEASE}-RC${RC_NUM}' (Commit_1)
> # sets version in gradle.properties to back to '${RELEASE}-SNAPSHOT'
> (Commit_2)
> Commit_1 will also be tagged as (tag: v${RELEASE}-RC${RC_NUM})
> Afterwards, we continue with 'Commit_2' in testing, bundling and publishing.
> I.e. looking into source distribution published, this is not the one tagged,
> but its successor. This is probably suboptimal.
> The release plugins expectations would probably more along the lines to
> actually increment next version (either patch, minor or even major) and
> release on that Commit_1.
> Based on my current understanding, it seems easier to either
> * drop usage of gradle release plugin and just fall back to a plain 'exec
> git tag'
> * use a beam-release task which depends on gradle release checks, but does
> no version changes nor commits
> The former has the drawback to also drop the checks done by release plugin,
> e.g.
> * checkCommitNeeded
> * checkUpdateNeeded
> * checkSnapshotDependencies
> * runBuildTasks
> * createReleaseTag
> which might be still valuable.
> [1]
> [https://lists.apache.org/thread.html/205472bdaf3c2c5876533750d417c19b0d1078131a3dc04916082ce8@%3Cdev.beam.apache.org%3E]
> [2]
> [https://github.com/apache/beam/blob/master/release/src/main/scripts/build_release_candidate.sh#L92-L94]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
