It makes sense. A statement on website with « release every quarter » would be great !
+1 Regards JB Le sam. 7 oct. 2023 à 20:09, Fokko Driesprong <fo...@apache.org> a écrit : > 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 >>> >>
