Yes, the TL;DR is that we do not at this time intend to make minor LIBRARY releases in SemVer parlance, even if there are no backwards incompatible changes. Either we will make Major releases or Patch releases of the libraries. We will likely make minor releases of the columnar protocol, though.
The other questions are handled in the Versioning document, we are now observing a dual-versioning scheme with FORMAT version being separate from LIBRARY version. Each version of the libraries will have a corresponding FORMAT version, and the format version will change more slowly than the libraries. So LIBRARY version 2.0.0 may use FORMAT version 1.0.0 unless new features are added in which case the format version may be 1.1.0 On Mon, Jul 27, 2020 at 11:54 AM Neal Richardson <neal.p.richard...@gmail.com> wrote: > > https://arrow.apache.org/docs/format/Versioning.html is the statement that > came from the resolution of the previous discussion. IIRC the discussion > came between the 0.15 and 0.16 releases, if you want to search the mailing > list archives. > > I wouldn't want to speak for everyone, but I believe there are a few things > at play: > > * Release logistics: I believe the community has decided that it wants to > continue releasing all components at the same time, in which case having a > single release number greatly simplifies things. > * Compatibility of libraries: it's a lot easier to know that two libraries > in different languages are compatible because they have the same number. > * Version numbers are cheap, and (IMO) there's little useful information in > version numbers other than "higher means newer" (unless you're in Python > and have parallel major releases for years ;) > > While I might also question whether the next release for the library I'm > working on "should" have a major or minor version bump, I'm skeptical that > having that autonomy is worth the maintenance cost. > > Neal > > > On Mon, Jul 27, 2020 at 9:37 AM Jorge Cardoso Leitão < > jorgecarlei...@gmail.com> wrote: > > > Hi > > > > First off, congrats for the 1.0.0 release! > > > > I am writing because I am trying to understand the versioning schema we > > will use going onwards. > > > > AFAI understand, 1.0.0 was assigned to all subcomponents of arrow. I.e. I > > can now use pyarrow and assign something like >=1,<2 on a setup.py. > > > > However, looking at other parts of the project, I get the feeling that > > these components are less mature / more recent, and likely need more > > backward incompatible changes until a stable API is achieved. In other > > words, within arrow, I get the feeling that different parts are at > > significantly different stages of their development lifetime. > > > > How are we planning to reconcile this fact? E.g. I can see pyarrow not > > wanting to bump from 1 to 2 since no backward incompatible change was > > introduced, while other components have backward incompatible changes. > > > > A related question: what exactly are we versioning with this 1.0.0? The > > protocol? The individual APIs? The project as a whole? > > > > In my view, there is a case here to _not_ align the versions of the > > different components, exactly to avoid having one component's version (e.g. > > pyarrow) be dependent on other's code (e.g. rust arrow). However, I suspect > > that this discussion has already taken place and I have been unable to find > > a summary of it. > > > > Best, > > Jorge > >
