Good point. Imho, we should increment API versions when we introduce "breaking changes". On major versions, I don't see a need to support previous API versions. Users who want to support previous API can always use previous Polaris versions. For us, we can "maintain" two major versions in parallel (the last one with active new features, improvements, and bug fixes on both the last version and previous one).
For instance, in the Apache ActiveMQ project maintains both ActiveMQ 5.x and 6.x, with complete different API support (ActiveMQ 5.x implements javax.jms 1.1, whereas ActiveMQ 6.x implements jakarta.jms 3.1). So, regarding your example, I would say that Polaris 2.0 should not necessary support v1 APIs, but focus on vX APIs and important changes. We can still maintain Polaris 1.x for v1 API (with dependency updates and bug fixes). Regards JB On Tue, Oct 22, 2024 at 12:10 AM Michael Collado <collado.m...@gmail.com> wrote: > > What's the support policy for API versions? Do we increment API versions > for breaking API changes (this seems reasonable and likely)? And do we > support previous API versions for some period of time? > > If the answer to both of those questions is "yes" , then what is the > purpose of fast major verison releases? If we ship Polaris 2.0, shouldn't > the service still support the v1 APIs? For me, a 2.0 release should mean > pretty radical changes - new features, such as non-Iceberg table support, > delegated Authz policies, etc. > > On Mon, Oct 21, 2024 at 11:53 AM Yufei Gu <flyrain...@gmail.com> wrote: > > > I'm not opposed to rapid evolution, but I’m trying to understand the > > reasoning behind the fast major version. It’s ultimately a tradeoff between > > maintaining backward compatibility and advancing quickly through breaking > > changes—we can’t achieve both at the same time. A faster major version > > release seems to indicate a preference for rapid progress over stability. > > Otherwise, why push for it? Am I missing something? > > > > Yufei > > > > > > On Mon, Oct 21, 2024 at 11:26 AM Dmitri Bourlatchkov > > <dmitri.bourlatch...@dremio.com.invalid> wrote: > > > > > IMHO, production compatibility concerns are valid, but they are not > > related > > > to the versioning scheme. > > > > > > Backward-compatibility breakage should be declared anyway, whether the > > move > > > is from 0.42.1 to 0.43.0 or from 2.1.1 to 3.0.0. > > > > > > Still, bumping a major version indicates major change. It does not > > > automatically indicate incompatibility. My reading of Semver [1] > > guidelines > > > is that major must be incremented when incompatible changes are present, > > > but there is no restriction on incrementing major and keeping the product > > > backward compatible. > > > > > > On the other hand, if we avoid major code changes because of the risk of > > > incompatibility, that will slow down the project's evolution. > > > > > > Cheers, > > > Dmitri. > > > > > > [1] https://semver.org/ > > > > > > On Mon, Oct 21, 2024 at 2:07 PM Yufei Gu <flyrain...@gmail.com> wrote: > > > > > > > +1 on moving forward with 0.9 as the first version! > > > > > > > > I have some concerns about fast major versioning, especially with > > > > compatibility. Since the catalog is crucial in production, teams may be > > > > reluctant to upgrade, particularly with breaking changes. > > > > > > > > Does fast versioning help in this case, or could it make things harder? > > > > Does it encourage more frequent upgrades, and is there a plan to manage > > > > production impact? While we can't completely avoid user forks, we want > > to > > > > minimize divergence. > > > > > > > > Yufei > > > > > > > > > > > > On Fri, Oct 18, 2024 at 6:33 AM Dmitri Bourlatchkov > > > > <dmitri.bourlatch...@dremio.com.invalid> wrote: > > > > > > > > > +1 to "fast" major version. > > > > > > > > > > Cheers, > > > > > Dmitri. > > > > > > > > > > On Fri, Oct 18, 2024 at 5:17 AM Jean-Baptiste Onofré < > > j...@nanthrax.net> > > > > > wrote: > > > > > > > > > > > Hi folks, > > > > > > > > > > > > First of all, thanks everyone for the first community meeting > > > > > > yesterday. It was a great meeting, very interesting discussions. > > > > > > You can find the meeting notes on the Polaris website > > > > > > (https://polaris.apache.org/community/meetings/): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1TAAMjCtk4KuWSwfxpCBhhK9vM1k_3n7YE4L28slclXU/edit?usp=sharing > > > > > > > > > > > > As discussed during the meeting, here's the release proposal: > > > > > > - the first Polaris release will be 0.9. I'm doing a new pass on > > the > > > > > > preparation steps (due diligence on > > > > > > NOTICE/LICENSE/DISCLAIMER/dependencies, automatic "scripts", etc). > > As > > > > > > we are mid October, I propose to actually release 0.9 at the > > > beginning > > > > > > of November. > > > > > > This release is to verify our distribution with both the Polaris > > > > > > community and also the Apache Incubator (IPMC). > > > > > > - After 0.9 release, I propose to move forward to 1.0 release (I > > > think > > > > > > it would be great to have 1.0 release before end of the year) > > > > > > - I also think we should use the "fast" major version as soon as we > > > > > > introduce any breaking change. I don't see a problem with having > > > > > > Polaris 1, Polaris 2, Polaris 3, ... quickly if needed. > > > > > > > > > > > > Regards > > > > > > JB > > > > > > > > > > > > > > > > > > > >
