And we just use 2 level workflow, and have branches for each of the 'releases' [as we move from one to the other] $ git branch -r |egrep 'origin/(maint|release)-' origin/maint-3.10 origin/maint-3.11 origin/maint-3.12 origin/maint-3.2 origin/maint-3.3 origin/maint-3.4 origin/maint-3.5 origin/maint-3.6 origin/maint-3.7 origin/maint-3.8 origin/maint-3.9 origin/maint-tao-2.2 origin/release-3.13 origin/release-3.14 Satish On Wed, 31 Mar 2021, Satish Balay via petsc-dev wrote:

...

...

...

...

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]

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]

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 ?