+1 To Julian's amendment. Thanks for sorting this out, Julian + Stamatis.
The release process for Calcite is quite involved and can be somewhat
complex. I think we should consider adding explicit instructions to the
HOWTO document with the exact git commands need to even the site and
master branches after the finalization of a release.
The current instructions just say to do a fast-forward merge from the
release branch back to master.
I think the addition would be immensely helpful for future RMs (I
believe the next few RMs for Calcite have not made a Calcite release
before, previously).
On 28/03/2019 10:13 am, Michael Mior wrote:
LGTM. Thanks for sorting this out!
--
Michael Mior
[email protected]
Le mer. 27 mars 2019 à 19:12, Julian Hyde <[email protected]> a écrit :
I saw that Stamatis just did “git push origin a9687de81:site”. That’s somewhat
of an improvement, because it removes the merge commit, but it introduces a
problem: it includes “25ffeb4ac [CALCITE-2908] Implement SQL LAST_DAY
function”, and that commit updates the site with a function that will not be in
the product until 1.20.
I’m just about to push 42dce0928. That commit contains only commits that change
the site, cherry-picked from master. I hope people view that as an improvement.
Julian
$ git log --graph --abbrev-commit --pretty=oneline site origin/site --
* 42dce0928 - (HEAD -> site) Site: Add Alibaba MaxCompute to po
* 1939f9c68 - Suppress deprecation warning, and remove unicode
* 819722500 - Site: Add new committers (Haisheng Yuan, Hongze Z
* a5530e5fb - [CALCITE-2952] Add JDK 12 as tested to 1.19.0 his
| * a9687de81 - (origin/site, origin/master) [CALCITE-2958] Upg
| * 650d24b9a - Site: Add Alibaba MaxCompute to powered-by page
| * ddbcd3955 - Suppress deprecation warning, and remove unicod
| * 1f4b61989 - [CALCITE-2796] JDBC adapter should convert 'GRO
| * 4fdf241df - In RelFieldCollation, add a "withX" copy method
| * 90e69d418 - [CALCITE-2953] LatticeTest.testTileAlgorithm2 a
| * 11c067f99 - Site: Add new committers (Haisheng Yuan, Hongze
| * 35ab6c768 - [CALCITE-2952] Add JDK 12 as tested to 1.19.0 h
| * 1b430721c - [CALCITE-574] Remove org.apache.calcite.util.Bu
| * 81143c830 - [CALCITE-589] Extend unifyAggregates method to
| * 25ffeb4ac - [CALCITE-2908] Implement SQL LAST_DAY function
|/
* 406129b97 - [CALCITE-2951] Support decorrelate subquery that
* 2fa7fd79b - [CALCITE-2946] RelBuilder wrongly skips creation
* ecc100ea2 - [CALCITE-2943] Materialized view rewriting logic
* 79f432457 - [CALCITE-2942] Materialized view rewriting logic
* 06b1894db - Site: News item for release 1.19.0 (2 days ago) <
* b8f4edfcf - (origin/branch-1.19) [maven-release-plugin] prepa
On Mar 27, 2019, at 3:57 PM, Haisheng Yuan <[email protected]> wrote:
+1
Thanks~
Haisheng Yuan------------------------------------------------------------------
发件人：Francis Chuang<[email protected]>
日 期：2019年03月28日 06:49:44
收件人：<[email protected]>
主 题：Re: Site branch
+1 I think this should reduce the number of "commits ahead" in the site
branch compared to master to 0.
On 28/03/2019 9:46 am, Julian Hyde wrote:
The site branch currently has a merge commit in it. But traditionally after a
release the site branch points to the same commit as the master branch.
So, any objections if I reset the site branch, as follows:
$ git checkout site
$ git reset —hard origin/branch-1.19
$ git push -f origin site
Then cherry-pick a couple of commits from master that need to go into the site.
To my eyes at least, that creates a simpler & clearer history.
Julian
