Satish Balay via petsc-dev <[email protected]> writes: >>>>> > https://semver.org/ > > Given a version number MAJOR.MINOR.PATCH, increment the: > > MAJOR version when you make incompatible API changes, > MINOR version when you add functionality in a backwards compatible > manner, and > PATCH version when you make backwards compatible bug fixes. > <<<< > > For one - we don't strictly use semantic versions. > > - Our PATCH versions have (some) new functionality [from above that should be > MINOR] > - Our MINOR versions have lot more new functionality, with some incompatible > API changes [this should be MAJOR - but we haven't changed that in a while]
I think the idea is that petsc-4.x is being reserved for a hypothetical petsc-future, while 3.x is everything with modest incremental changes from where we are now. To apply semantic versioning, some projects just increase the major number -- we have Firefox 87 and Chromium 89. Linux was 2.6.x for ages and then just declared they would start incrementing the major and minor versions despite an equivalent compatibility policy. So they did 3.0 - 3.19, 4.0 - 4.20, and are now 5.11. I'm happy with our current 3.x strategy, reserving 4.x for something with potentially more cross-cutting changes (even a new primary implementation language), though an incremental migration strategy would still need to be present. > Wrt v3.15.0 vs v3.15 I don't remember the exact reason. I suspect we > just stuck with this notation for a long time [and didn't want to > change it] I believe we were adopting the convention from Git and others. > Also Barry still wants to use 'release' term only with v3.15 - and 3.15.1 etc > as updates [but not releases] > > Satish > > On Wed, 31 Mar 2021, Lisandro Dalcin wrote: > >> Satish, if we use semantic versioning for the PETSc version itself and the >> tarball, why don't we use the same format for tags? In short, why aren't we >> using v3.15.0 instead of v3.15 ? >> >>
