> On Nov 9, 2017, at 8:00 PM, Thomas Mansencal <[email protected]> > wrote: > > The fact it is backward incompatible raised to me the question of OIIO > versioning scheme. What is the current approach since it does not seem to > follow semantic versioning?
I think for the pedantic, "semantic versioning" has three levels of release with numbering MAJOR.MINOR.PATCH: MAJOR: changes that can break APIs arbitrarily MINOR: changes that can add new API, but not break old API PATCH: bug fixes only, not even additions of new calls On OIIO, we roll both bug fixes and low-risk non-breaking additions into the minor releases (1.7.7 vs 1.7.8), never have true "bug fix only" releases. But we religiously adhere to the distinction that back-compatibility changes can only happen for major releases (1.8 vs 1.9). Anything goes in master, it's not a release branch at all yet -- that's where we can make big changes, including breaking APIs, as we are doing here. Every several months, we branch a new (major) release branch from master. Now that I'm writing this, I realize that I've been sloppy in the following way: I call 1.7 -> 1.8 a major release and 1.2.3 -> 1.2.4 a minor release. But if you look in oiioversion.h, it calls the first digit MAJOR_VERSION and the second digit MINOR_VERSION. So the nomenclature doesn't match. I'm not proud of this, but I'm worried that it's needlessly disruptive to change it all for the sake of pedantry. In all practical senses, we make the same distinction between API-breaking releases (major) and non-breaking releases (minor), and that's the important principle. We just don't assign the digits the same way as true Semantic Versioning (TM). -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
