I think there are two kinds of releases: 1. Feature release. That means to upgrade the minor part of the version number, e.g. 1.4.0, 1.5.0, etc. 2. Patch release. That's bug fixes to minor releases, which upgrades to the last part of each release version, e.g. 1.4.1, 1.4.2.
I think the quarterly release should be applied to feature release, while patch release should be more frequent to fix bugs. On Sat, Oct 7, 2023 at 3:20 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Just to be concrete about "regular & predictable releases pace", the > proposal is to have one line on https://iceberg.apache.org/releases/ > like this: > > "Apache Iceberg releases are expected every quarter. Next target > release is 1.4.1 planned on Jan 24." > > To be honest, only a few Apache projects do that (Karaf, Camel, > ActiveMQ, Subversion, ...), I like this to give "vision" to the > community :) > > Regards > JB > > On Sat, Oct 7, 2023 at 6:59 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > > Hi Ryan, > > > > For the pace, yes, it's what I saw with the previous release date. My > > proposal is to clearly state that on website (on release page), > > something like "We target a release per quarter". Just to inform the > > community. > > > > About the other points: > > 2.1. Great, thanks ! > > 2.2. Yes, release notes on releases page are fine. The proposal is > > more to have some details about specific highlight points, with > > examples for instance. Something like > > > http://nanthrax.blogspot.com/2022/04/apache-karaf-runtime-440-has-been.html > . > > It's a bit long for a release notes page, so it could be "linked" on > > release notes page. About your point, I agree, but we already have > > https://iceberg.apache.org/blogs/ with posts from different people. > > How do we choose the blog posts here ? I guess these blog posts have > > been submitted as PR and reviewed/merged. Maybe we can use the same > > for release highlights ? > > 2.3. The cleanup should be done as soon as a new release is uploaded > > to dist.apache.org (for instance, we still have Iceberg 0.14.1 on > > https://dist.apache.org/repos/dist/release/iceberg/). The tags cleanup > > is up to us, but for dist, ASF INFRA asks for cleanup (we should have > > only the latest release on dist.apache.org) to limit the space use. > > 2.4. Cool, thanks ! I'm updating the PR with the DOAP. > > > > Thanks again ! Much appreciated :) > > > > Regards > > JB > > > > On Fri, Oct 6, 2023 at 8:34 PM Ryan Blue <b...@tabular.io> wrote: > > > > > > 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 > -- Renjie Liu Software Engineer, MVAD
