The advantage of a release branch is that we don’t need to force-push to master when we make a mistake.
Let’s continue to use a release branch. Julian > On Feb 29, 2020, at 07:25, Stamatis Zampetakis <zabe...@gmail.com> wrote: > > In the last release of avatica we didn't release two archives in the end > (but only the .tar.gz) [1]. > Before that for a quite some time we were releasing only the tar.gz archive. > I would suggest to do the same for this, and the following Calcite > releases, until we reach some consensus around the problem of line endings > [2, 3]. > > Best, > Stamatis > > [1] > https://lists.apache.org/thread.html/18911eed28dc11f7c21679f244b66426822961406cf3fa4ab9834fbb%40%3Cdev.calcite.apache.org%3E > [2] > https://lists.apache.org/list.html?dev@calcite.apache.org:lte=1M:%5BVOTE%5D%20Release%20apache-avatica > [3] > https://lists.apache.org/thread.html/87f2973a1e78237cc001df360a837c1b170342aa6d84a2d2c482f867%40%3Cdev.calcite.apache.org%3E > >> On Sat, Feb 29, 2020 at 9:51 AM Vladimir Sitnikov < >> sitnikov.vladi...@gmail.com> wrote: >> >> Danny, thanks for putting things together, however, I guess the vote mail >> requires clarifications before the votes can be cast :-/ >> >> Danny>The hashes of the artifacts are as follows: >> >> dist.apache.org contains two archives, however, the vote mail lists just >> one of them. >> We had the very same case with 1.21.0 vote: >> >> https://lists.apache.org/thread.html/ebfdfc6d3ac0f81801d805dec014f10507ee9cd7af63cac2999aeb19%40%3Cdev.calcite.apache.org%3E >> >> Danny, can you please double-check all the release artifact checksums you >> are going to release via dist.apache.org? >> >> >> Danny>Release artifacts are signed with the following key: >> Danny>https://people.apache.org/keys/committer/danny0405.asc >> >> Is this key on the ASF web of trust? >> I'm not sure that is a hard requirement for release signing, but I guess >> historically we used the keys that were cross-signed by other >> PMC/committers. >> >> Danny>You can read the release notes here: >> Danny> >> https://github.com/apache/calcite/blob/calcite-1.22.0/site/_docs/history.md >> >> Did you create calcite-1.22.0 tag manually? >> I thought the build script should have created calcite-1.22.0-rc2, >> however, I do not see it. >> >> It looks sad to have the very same link /calcite/blob/calcite-1.22.0/site/ >> in different mails :-/ >> Then, it is not clear how to compare what has changed between the release >> candidates. >> >> The naming of calcite-1.22.0 tag is confusing: it can easily be confused >> with a true release tag (see >> >> https://lists.apache.org/thread.html/ra2bfc17c52d80250ed9848a1977ac23807282ab4c1c1b643625b36a8%40%3Cdev.calcite.apache.org%3E >> ) >> >> Do we really need a release branch? Why can't we build candidates out of >> the master? >> I guess if we had calcite-1.22.0-rc0, -rc1, and so on tags right in the >> master branch, then everybody would see there's a release pending. >> >> Vladimir >>
