Thanks JB and Ryan. Makes sense to not have a EOL policy since a vote-based new release is always possible for Apache projects. Other than that, a single Iceberg release includes the new changes for multiple Spark/Flink versions. For example, the 1.3.0 release covers Spark 3.1, Spark 3.2, Spark 3.3 and Spark 3.4. This also reduces the chance to patch an old release.
Yufei On Tue, Aug 1, 2023 at 10:50 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Ryan, > > I agree about EOL, and actually it doesn't really exist for Apache > projects (anyone can trigger a release on an old branch if needed). > That's why in Karaf for instance (and few other Apache projects), I > prefer to use active/non active on branches, just to indicate to the > community that we have some branches where we are focusing (for bug > fixes or dep updates). > The "forks" made by organizations are under the responsibility of > those organizations, the Iceberg community decides the > active/non-active branches :) So I agree with you Ryan about > "community patch releases". > > Regards > JB > > On Wed, Jul 26, 2023 at 9:19 PM Ryan Blue <b...@tabular.io> wrote: > > > > My main question is whether an EOL policy provides additional value. > Most projects that provide EOL guidance (say Spark and Java) aren't like > Iceberg. They are software projects that are directly deployed by people > using them and they are generally hard to upgrade (or downgrade) > incrementally. Iceberg, on the other hand, is a library that makes strong > guarantees about the format it produces and consumes: > > * Iceberg is deployed bundled with services like EMR or in releases of > Trino that manage updates > > * When Iceberg is depended upon directly, it is usually easy to upgrade > incrementally across jobs, rather than all at once > > * Iceberg provides forward- and backward-compatibility guarantees to > ensure that older versions continue to work alongside newer ones > > > > As a result, most organizations I know of have several versions of > Iceberg deployed at the same time and people are generally able to upgrade > if there's something in a newer release that they need. Given that > flexibility, I think it's fairly easy to upgrade and keeping on a > particular minor release for a long time isn't nearly as important as for > Java or Spark. That's why I'm wondering if it would actually be helpful for > us to provide an EOL policy. > > > > I think the counter-argument to this is that some organizations branch > Iceberg and maintain those branches for a long time. But in those cases, do > we need the community to continue maintaining the base of that branch? I > did this for a long time at Netflix and I'm not convinced that community > patch releases are needed. > > > > JB, we do have multiple branches and release older versions from time to > time if there is a serious enough bug to warrant a patch release. > > > > Ryan > > > > On Tue, Jul 25, 2023 at 10:37 PM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> > >> Hi, > >> > >> At Apache, a strong EOL/LTS policy doesn't really exist: anyone can > >> cut a new release on a very old branch as soon as it's voted by at > >> least three binding votes. > >> > >> That said, a lot of Apache projects have EOL/LTS policy defined in the > project: > >> - for instance Apache Camel has LTS branches > >> (https://camel.apache.org/download/) > >> - Apache Karaf talks more about active/non active branches defining > >> which branches are still "maintained/active" > >> (https://karaf.apache.org/download.html) > >> > >> I think it would be good to have EOL/LTS details for Iceberg in > >> https://iceberg.apache.org/releases/. > >> > >> Before that, we should have a consensus about the policy :) > >> Correct me if I'm wrong, but we have only "one active branch" which is > >> basically main (where we cut releases). Do we plan to have multiple > >> active branches (for instance 1.3.x and 1.4.x) ? > >> Do we plan to flag some releases at LTS ? > >> > >> Regards > >> JB > >> > >> On Mon, Jul 24, 2023 at 8:08 PM Yufei Gu <flyrain...@gmail.com> wrote: > >> > > >> > Hi folks, > >> > > >> > I was thinking about how we handle the Iceberg releases, and it seems > that we don't currently have a clear EOL (End of Life) strategy in place. > At least, we don't specify an EOL timeline for our releases on our official > page (https://iceberg.apache.org/releases). I believe it would be helpful > for our users if we could indicate when a particular release will no longer > be supported or receive updates. > >> > > >> > What do you think about setting up an EOL policy? We could go for a > vote-based approach or have a fixed lifecycle for each release. Either way, > this could help our users plan their upgrades and keep their systems > updated more effectively. > >> > > >> > Looking forward to hearing your thoughts! > >> > > >> > Best, > >> > > >> > Yufei > > > > > > > > -- > > Ryan Blue > > Tabular >
