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
