You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iceberg.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2023/10/06 09:00:28 UTC
[PROPOSAL] Regular release pace & some post release actions
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 announce@apache.org.
The last "official" announcement we did was for Iceberg 1.0.0. As
announce@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 announce@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
Re: [PROPOSAL] Regular release pace & some post release actions
Posted by Fokko Driesprong <fo...@apache.org>.
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 <dw...@apache.org>:
> 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 <fo...@apache.org> 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é <jb...@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 <li...@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é <jb...@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é <jb...@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 <bl...@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é <
>>>>> jb@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
>>>>> announce@apache.org.
>>>>> > >> The last "official" announcement we did was for Iceberg 1.0.0. As
>>>>> > >> announce@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 announce@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
>>>>
>>>
Re: [PROPOSAL] Regular release pace & some post release actions
Posted by Daniel Weeks <dw...@apache.org>.
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 <fo...@apache.org> 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é <jb...@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 <li...@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é <jb...@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é <jb...@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 <bl...@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é <
>>>> jb@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 announce@apache.org
>>>> .
>>>> > >> The last "official" announcement we did was for Iceberg 1.0.0. As
>>>> > >> announce@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 announce@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
>>>
>>
Re: [PROPOSAL] Regular release pace & some post release actions
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@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 <li...@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é <jb...@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é <jb...@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 <bl...@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é <
>>>> jb@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 announce@apache.org
>>>> .
>>>> > >> The last "official" announcement we did was for Iceberg 1.0.0. As
>>>> > >> announce@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 announce@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
>>>
>>
Re: [PROPOSAL] Regular release pace & some post release actions
Posted by Fokko Driesprong <fo...@apache.org>.
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é <jb...@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 <li...@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é <jb...@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é <jb...@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 <bl...@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é <jb...@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 announce@apache.org.
>>> > >> The last "official" announcement we did was for Iceberg 1.0.0. As
>>> > >> announce@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 announce@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
>>
>
Re: [PROPOSAL] Regular release pace & some post release actions
Posted by Jean-Baptiste Onofré <jb...@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 <li...@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é <jb...@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é <jb...@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 <bl...@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é <jb...@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 announce@apache.org.
>> > >> The last "official" announcement we did was for Iceberg 1.0.0. As
>> > >> announce@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 announce@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
>
Re: [PROPOSAL] Regular release pace & some post release actions
Posted by Renjie Liu <li...@gmail.com>.
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é <jb...@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é <jb...@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 <bl...@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é <jb...@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 announce@apache.org.
> > >> The last "official" announcement we did was for Iceberg 1.0.0. As
> > >> announce@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 announce@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
Re: [PROPOSAL] Regular release pace & some post release actions
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@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 <bl...@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é <jb...@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 announce@apache.org.
> >> The last "official" announcement we did was for Iceberg 1.0.0. As
> >> announce@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 announce@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
Re: [PROPOSAL] Regular release pace & some post release actions
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <bl...@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é <jb...@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 announce@apache.org.
>> The last "official" announcement we did was for Iceberg 1.0.0. As
>> announce@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 announce@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
Re: [PROPOSAL] Regular release pace & some post release actions
Posted by Ryan Blue <bl...@tabular.io>.
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é <jb...@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 announce@apache.org.
> The last "official" announcement we did was for Iceberg 1.0.0. As
> announce@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 announce@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