The Iceberg community has already established a regular release cadence, which is once per quarter. Here's the recent release history, minus patch releases:
- 1.4.0: 2023-10-04 - 1.3.0: 2023-05-26 - 1.2.0: 2023-03-20 - 1.1.0: 2022-11-29 - 1.0.0: 2022-10-14 - 0.14.0: 2022-07-16 As you can see, we've generally met the target, so I'm not sure why you're suggesting a change. If your aim is for more strict adherence to the quarterly release target, I don't think that's a good idea. I think I've mentioned this before, but I think we want to avoid strict policies that inhibit our ability to make reasonable decisions as a community, as was the case here to get Spark 3.5 out as soon as possible. For your other suggestions: 2.1. Sure, let's send announcements to the announce list. Note that this has to happen after the website is updated, which causes delays right now. We're working on fixing this. 2.2. I don't think it is a good idea for the project to host blog posts because it puts the community in a very awkward position of choosing who can post and what content can be there. And I think what you're asking for is release notes, which we do post on the releases page. If you'd like to help make these better, please do! We always need help translating from PR descriptions to release notes that help people understand what is changing. 2.3. Yes, we do this periodically. We also need to clean up tags. 2.4. Go for it. As for the release guide, anyone is welcome to submit a pull request and we'd love to have you contributing. Ryan On Fri, Oct 6, 2023 at 2:00 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi guys, > > I would like to propose some improvements on our release. > > 1. Predictable & regular release pace > > We started this discussion quickly on the 1.4.0 vote thread: I think > it would be interesting for the community (both our users and also > companies leveraging Iceberg in their products) to have a regular & > predictable release pace. > It would give a kind of roadmap/expected dates for our users. > According to our previous release dates, I propose to target a release > per quarter. > It doesn't mean that we won't be able to release faster (if we want to > quickly include a fix or CVE or whatever, we can always cut a > release), but we would have a minimum of one release per quarter. As > today, the versioning will be discussed on the mailing list. > Website (https://iceberg.apache.org/releases/) should contain this > information and the next release target date. > > 2. Post release actions > > I propose some new actions post release: > > 2.1. Prepare an announcement email that will be sent to > dev@iceberg.apache.org and (also important) to annou...@apache.org. > The last "official" announcement we did was for Iceberg 1.0.0. As > annou...@apache.org is "processed" by the ASF communication team, and > Iceberg releases will be included in the ASF updates. > The release guide (https://iceberg.apache.org/how-to-release/) already > contains this point, but it seems we missed annou...@apache.org (it's > not obvious in the guide). I propose to be clearer on this point. > > 2.2. Write a blog post with highlights on the release. This "release > highlights blog post" should be on https://iceberg.apache.org/blogs/. > For instance, for 1.4.0, we could mention Spark 3.5 support, push down > function, distributed planning, etc. > > 2.3. When we update src distribution on dist.apache.org, we should > clean the previous release. Right now, > https://dist.apache.org/repos/dist/release/iceberg/ contains all > releases. ASF automatically copies all releases from dist.apache.org > to archive.apache.org (see https://archive.apache.org/dist/iceberg/). > Only the latest release should be on dist.apache.org, we should remove > previous releases and use archive.apache.org instead. I will propose a > PR for the website to use archive.apache.org for previous releases and > cleanup previous releases. > So, the action proposal here is to remove previous release artifacts > after new release upload. > Again, the release guide (https://iceberg.apache.org/how-to-release/) > mentions the upload of artifacts, but not the cleanup. > > 2.4. We have a PR to upload the Iceberg DOAP file to the iceberg > repo (https://github.com/apache/iceberg/pull/8586). I propose to > update the DOAP file with new release (I will update the PR with all > releases). > > If you agree with these topics, I'm volunteer to update the Release > Guide (https://iceberg.apache.org/how-to-release/) with these points. > I'm also volunteering for the next release to test/validate this process. > > Thoughts ? > > Thanks, > Regards > JB > -- Ryan Blue Tabular
