[ 
https://issues.apache.org/jira/browse/DATAFU-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthew Hayes closed DATAFU-136.
--------------------------------
      Assignee: Matthew Hayes
    Resolution: Fixed

Updated instructions in a697117793df3f5462500a0d2e229b8726d4ea18.

> Evaluate gradle.properties release flag updating for releases
> -------------------------------------------------------------
>
>                 Key: DATAFU-136
>                 URL: https://issues.apache.org/jira/browse/DATAFU-136
>             Project: DataFu
>          Issue Type: Improvement
>            Reporter: Matthew Hayes
>            Assignee: Matthew Hayes
>            Priority: Minor
>
> Currently the {{release}} property in {{gradle.properties}} is updated when 
> preparing the source tarball for release:
> {noformat}
> ./gradlew clean release -Prelease=true{noformat}
> The issue here, raised by [~rvs], is that the {{gradle.properties}} file in 
> git at the release tag does not match the corresponding file in the source 
> release.  So for the source release you can run {{./gradlew assemble}}  to 
> produce the release artifacts but in the git clone you need to run 
> {{./gradlew assemble -Prelease=true}}.  
> The thought behind the current approach:
>  
> 1) Building from git checkout of master or release branches should not 
> produce "release" artifacts.  These should have "SNAPSHOT" in the name.
> 2) Building from a source release should produce "release" artifacts.
>  
> Another requirement we should add based on Roman's feedback:
>  
> 3) Building from a git release tag should produce the same "release" 
> artifacts as building from the source tarball.
>  
> To take the 1.3.3 release as an example, one way to achieve this would be 
> cutting a 1.3.3-rc0 or 1.3.3-rc1 branch for the sole purpose of setting the 
> release flag in gradle.properties.  Then we can tag it with release-1.3.3-rc0 
> or release-1.3.3-rc1.  This allows us to still merge the 1.3.3 branch into 
> master with whatever additional fixes were made there without worrying about 
> bringing in the gradle.properties change.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to