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 >
