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