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