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
