I think that your proposal should work fine. It does not matter much how we mark the development (or snapshot) version in the master branch. The important part is that it should be the next minor version with respect to the latest frozen release branch, which we follow already, plus some suffix indicating that it is a work in progress.
I agree that we should eventually move the Python part into a separate repository, but we don't have to do it right now. On Thu, Nov 3, 2022 at 2:25 AM Jon Malkin <[email protected]> wrote: > Hi DS dev community, > > Realizing I'd screwed up version numbering in the recent patch release > candidate has made me finally act on cleaning up our versioning situation. > I'm looking to create an input file that can hold a common version for both > c++ and python (an even better option would be to split python into its own > repo, but...I'm not there yet). > > It turns out that cmake and python have different -- and conflicting! -- > version standards. Releases are fine, but development versions, which are > really just placeholders since releases are governed by Apache policies, > are incompatible. > > Python format: N!]N(.N)*[{a|b|rc}N][.postN][.devN] > (https://peps.python.org/pep-0440/ > <https://urldefense.com/v3/__https://peps.python.org/pep-0440/__;!!Op6eflyXZCqGR5I!GY4gtHwDxLic8rhk1GLtHgvF79PKFLmqTpjBoLmyZuqX2USy2CcskfPbAuxbM1yXrwmYSueCIfZW781f3w$> > ) > > CMake format: either <major>.<minor>.<patch>[-rc<n>] for > release(-candidate)s or <major>.<minor>.<date>[-<id>] > (https://cmake.org/cmake/help/v3.16/variable/CMAKE_VERSION.html > <https://urldefense.com/v3/__https://cmake.org/cmake/help/v3.16/variable/CMAKE_VERSION.html__;!!Op6eflyXZCqGR5I!GY4gtHwDxLic8rhk1GLtHgvF79PKFLmqTpjBoLmyZuqX2USy2CcskfPbAuxbM1yXrwmYSueCIfazf2DZZQ$> > ) > > Since we shouldn't be tagging or publishing development versions, I'm > proposing we use cmake's major.minor.date-id format, replacing the - with a > . in python. The id would be "dev0" in this case, which I believe will meet > both format requirements. It's a little undesirable to use a datestamp a as > 3rd value when sorting, but that's where not tagging or publishing > development snapshots comes in. > > Any thoughts? Or should I not even bother with this and just work on > pulling python into its own repo? I think I'd prefer to do the latter when > we're _not_ gearing up for a major version bump since I feel like that'll > ultimately be less disruptive for library users. > > jon >
