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
