I've just tagged the current head of master as "developer preview" Release-2.1.0-dev.
It has come to my attention that some groups outside SPI also use master in production, and I realize I haven't made that easy by giving any cues about where is a smart place to do that or where compatibility breaks happen. I will be better at this, to wit: I will start tagging frequent (monthly or more) developer previews (designated by ending in "dev" and being based off the master branch) at stable points where I can endorse using it in production (and assure you that we do at SPI). I will mark and announce them with similar frequency to how we do stable releases, and expect them to be truly production-worthy, but note that they differ from supported release branches in the following ways: * Dev previews in master are allowed to break ABI or even API compatibility arbitrarily. In contrast, "release" branches guarantee that patch releases within that branch are completely back-compatible for link/ABI. * They will never be backpatched. "Fixes" will always require upgrading to a more recent developer snapshot in master, even if there have been compatibility breaks in the interim. Moving forward, for release branches (RB-x.y branches, anything but master), we are going to try to stick more closely to "semantic versioning" rules. In particular, we will try to make minor-number changes (2.1 -> 2.2) not break API back compatibility. We'd been lax about that, for example by removing deprecated methods or changing return types, but now we'll only do that at major version number boundaries (2.x -> 3.0, for example). Though we may still mark things as deprecated at minor version bumps... we just won't remove it, thus breaking link compatibility, until the next major version bump. True semantic versioning stipulates that patch releases (2.0.5 -> 2.0.6) contain bug fixes only, but we're going to interpret that loosely... still ensuring that we don't break ABI at those points, but will allow certain safe fully-back-compatible additions (calling them "design bugs" where we say feature X should have been there all along, so now we'll add it). -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
