My 2ct, There is no harm in stating it explicitly, however, I'm not in favor of making it so explicit by pinning a date onto it (Jan 24). I would rather say that releases can be expected at least every quarter (so it doesn't need to be updated :)
I noticed that the releases of Iceberg are also driven by the release cadence query engines. Once there is a new Flink or Spark release, an Iceberg release follows. I like to add *at least* because I see an uptake in the activity and I think want to release as often as possible, without introducing too much pressure on testing. Cheers, Fokko Op za 7 okt 2023 om 18:52 schreef Jean-Baptiste Onofré <j...@nanthrax.net>: > Yes, agree. Patch release is whenever needed. > The pace is more for « feature releases » and also the information on > website. > > Regards > JB > > Le sam. 7 oct. 2023 à 11:41, Renjie Liu <liurenjie2...@gmail.com> a > écrit : > >> 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 >> >
