I have pushed Release-1.2.0-beta2, which had only a few extremely minor fixes
compared to beta1. You should consider it a release candidate.
NOW is the time to try this out, if you are at all concerned about anything
being broken or incompatibilities with your old code.
In the absence of any emergencies, MONDAY 8 JULY 2013 is when I will tag an
official 1.2.0 release and thereafter consider 1.2 to be the production release
branch.
-- lg
On Jun 28, 2013, at 12:26 AM, Larry Gritz wrote:
> At long last, I have created the RB-1.2 branch, tagged as
> "Release-1.2.0-beta1". (Release notes / feature summary for 1.2 will be in a
> separate email -- they are very long, I probably should have cut a release a
> long time ago!)
>
> I'm calling this a "beta" for now, although since at SPI we build OIIO
> straight from master for certain production uses, I'm confident that the code
> is stable and production-hardened. But now is the time for those of you on
> 1.1 or earlier releases to give 1.2 a try, find anything broken or that needs
> immediate improvement, and we'll try to get it fixed in the next several days
> before I declare it "not beta." Even though we'll keep patching 1.2 with bug
> fixes, and perhaps enhancements that are low risk and don't break
> compatibility, I will strive not to break back compatibility with the API now
> that we've branched.
>
> The master branch has been bumped to "1.3.0" and is NOT an official release
> branch -- it's subject to occasional unstable code as we develop, and the API
> may change incompatibly at any time.
>
> That said, a lot of people do serious work with master, so I am making an
> important process change starting immediately: Previously I would call master
> 1.x.0 for months and months, with the official release in RB-1.x also called
> 1.x.0, and then start tagging and bumping the patch number (1.x.1, 1.x.2,
> etc.) for official releases. Now I'm going to start bumping patch number and
> tagging any time we introduce a change to master that breaks API or link
> compatibility. So by the time we "officially" branch and release a stable
> 1.3, it may be 1.3.13 or something, even though that's the first 1.3 that's
> advertised as being a stable, non-development release. Okay?
>
> So, to summarize the current state of the OIIO world (at least, once 1.2 is
> out of beta):
>
> * master: 1.3.x in development
> o New features get developed here. Occasionally unstable.
> o May break API or link compatibility without notice, but when we do,
> we'll
> bump the patch number and create a tag.
>
> * RB-1.2 1.2 branch - stable production release with 1.2.x releases
> o Will not break backward API or link compatibility within RB-1.2.
> o Will frequently have bugs fixed, and occasionally have features added
> if they
> are low risk (unlikely to break existing functionality) and high reward.
> o Will bump patch number and tag for "official" releases (approximately
> monthly).
>
> * RB-1.1 1.1 branch - the old stable production releases 1.1.x
> o As much as possible, locked down.
> o Will occasionally backport important bug fixes, but only at the request
> of
> specific users who are not yet able to upgrade to 1.2.
>
> * RB-1.0 or older:
> o Considered obsolete.
> o Hopefully will never be altered, though specific important bug fixes
> may be
> backported at the pleading request of specific users who are unable to
> upgrade.
>
>
> --
> Larry Gritz
> [email protected]
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
