+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 > > >
