Thanks again Danny for managing what proved to be a very complicated release! A few of my thoughts below:
- Yes, we should try to write good commit messages to remove the burden from the release manager - Personally I think we should use tags for releases consistent with what we have used in the past. I assume we can configure Gradle's release plugin to do so. - I personally would like to have the test sources still published since I use them in my Calcite notebooks project (https://github.com/michaelmior/calcite-notebooks) -- Michael Mior [email protected] Le ven. 6 mars 2020 à 09:54, Danny Chan <[email protected]> a écrit : > > About how/when the code is suitable for a release > > 1.22.0 is a huge release and we have many bug-fixes and improvements, but > also we changed a lot of code: > > > • The RexNode normalization and project names remove from digest did change a > lot of plan from the Apache Flink side > • Personally I fixed about 10+ bugs when I do a pre-validation for Apache > Flink 1.11.0-SNAPSHOT locally > > I believe the Calcite code is always in good quality and shape, but these > bugs still there, we need to find a way to reduce these bugs. > > Some fellows suggest to introduce a daily tests for other downstream > projects, maybe a good idea ~ > > About the release tag format > The release tag now changes from pattern calcite-x.y.z to rel/vx.y.z, which > is done automatically by the release plugin of current Gradle, we should make > a decision which pattern we should use ~ > > About the release note > Some fellows think that some of the commit messages are not that > readable/understandable, I have some thoughts here ~ > > > • It’s not easy to keep every commit message readable for the release > manager, we better do this when we merge the code > • We may need some part in the future to show the known issues/bugs which is > introduced in current release > • Do we need to put the credit (commit name) after each commit message ? It > seems many projects put the credits in the last part together of the release > note > > > About the release plugin > > I found some problems of the current release plugin work-flow(personal > feeling): > > • The RC artifacts was removed when I do the release, which actually I think > should not do, one awkward thing is that my network sucks, I failed in the > last step, so the RC artifacts removed but the release failed ~ > • The java doc doesn’t distinguish main API and test API, they are just > together [1] ~ > • The calcite-core does not publish the test sources now, should we add it > back ? > > [1] https://calcite.apache.org/javadocAggregate/ > > Best, > Danny Chan
