VulkanSceneGraph version convention, stable/LTS and unstable/development releases

[robertosfield]

Hi All,

Back on November 13th 2022 I tagged the 1.0.0 release since then I've been made "stable" patch releases most months bringing us 1.0.9 that was released on August 31st 2023. I write "stable" as the the API and ABI have been changing through this period of rapid improvement and refinement. These level of changes for a "stable" release series aren't anything close to a gold standard of how things are meant to be done - and as the project matures I want to move away from this moving target for stable releases.

In the OpenSceneGraph project we adopted the approach of stable point releases being "stable" and odd point releases being "development" and this worked well enough, so I've been wondering about following the same approach for the VulkanSceneGraph project, but haven't done up to now simply because the project has been under so much rapid development.

It occurred to me this morning there is similarities to this approach with the Ubuntu project that has the concept of "Long Term Support" releases that are made every 2 years, with interim releases every 6 months that have all the latest features but lack the same level of support.

Within the growing VulkanSceneGraph user community we'll have a range of users - ones that one to just pull pre-built libraries and headers from a 3rd party repository through to those that clone our githib repository and build the software themselves and pick either the releases tags to work from, or one of the branches.

I am stretched enough as it is that I simply can't directly support 3rd party repositories, so will continue to rely upon members of the community to provide this type of support. I am now thinking that, as a general principle, 3rd party repositories should just track the "stable" or "LTS" releases, and those that want interim releases will need to use our githib repo and build source themselves.

While I don't want to be tied to make a stable/LTS release every April in 2 year intervals, I think what would fit would be to use the even point release convention that we used for the OSG. So 1.0.x would a stable/LTS release series that is built of a 1.0 branch, then the next stable/LTS release series will be 1.2.x built off a 1.2 branch.

Then we have the development/unstable releases that we make regularly, and will have an odd point release number, so 1.1.0 will the first of this series and once the 1.1.x code base feels solid enough we'll make a 1.2 branch then make the next 1.2.x stable release series from this.

As a first step I have bumped the VSG and vsgExamples versions to 1.1.0-rc1, and once I've merged fixes and the pending PRs I'll make a call for testing and we can go for 1.1.0 release. I would discourage managers of 3rd party repos from tracking the 1.1.x releases as it's purpose will be lightweight releases that have unrestricted changes to API and ABI.

This leaves the VulkanSceneGraph-1.0 branch now on it's own and requiring it's own maintenance - so pulling in any fixes from master as well as fixes just to it. I remain really busy so am hoping that there won't be much need for lots of further 1.0.x releases at this point. The project is still changing quite quickly so I expect most users will want access to all the latest features in the 1.1.x series so continuing the 1.0.x will be less critical.

I think once we get to a point that making 1.2.0 would be appropriate then more effort can be made in maintaining a 1.2 branch and making 1.2.x stable releases.

Happy to take input on naming of the stable/LTS & unstable/development work. Sticking to one naming convention seems sensible to me.