There is also one post-upgrade that I would like to propose: https://github.com/apache/iceberg-docs/pull/280 We publish the releases also at Github <https://github.com/apache/iceberg/releases>, and I think that also gives a nice changelog. Now Python is in its own repository, no need to clean up the PyIceberg related pull-requests.
Kind regards, Fokko Op za 7 okt 2023 om 20:31 schreef Daniel Weeks <[email protected]>: > I would agree with Fokko here. We want flexibility with releases and > tracking to specific dates on the website just lends to unnecessary process. > > We also tend to track the release progress using github milestones > especially as we get closer to the release date, which provides more > context. Tracking in multiple places just leads to inconsistency. > > -Dan > > > > On Sat, Oct 7, 2023 at 11:09 AM Fokko Driesprong <[email protected]> wrote: > >> 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é <[email protected]>: >> >>> 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 <[email protected]> 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é <[email protected]> >>>> 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é <[email protected]> >>>>> 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 <[email protected]> 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é < >>>>> [email protected]> 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 >>>>> > >> [email protected] and (also important) to >>>>> [email protected]. >>>>> > >> The last "official" announcement we did was for Iceberg 1.0.0. As >>>>> > >> [email protected] 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 [email protected] >>>>> (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 >>>> >>>
