And there we go, the head of master has now had its version bumped to 1.8.0dev.
Anything goes in master (aka 1.8) from here on out. We can add or drop dependencies, change APIs, deprecate old versions of C++, etc. If you're testing, using, or making patches against 1.7 (which I promise will NOT have any of those radical things done to it), please be sure you're working from somewhere on the RB-1.7 branch. Barring any unforeseen problems that take longer than a day or two to fix, I'm planning to tag it and update the "release" branch marker to there, on *Saturday*. > On Sep 26, 2016, at 3:28 PM, Larry Gritz <[email protected]> wrote: > > I have tagged Release-1.7.6RC1 for testing as release candidate for 1.7. > > I hope to release for reals on Oct 1. > > At this point, only *critical* fixes will go into 1.7 branch while it's in > the RC stage. Anything else, even if safe enough for a release branch, will > not get merged into 1.7 until after the first non-RC 1.7 release. For the > next week, 1.7 is frozen to anything less than a major platform build break > or a critical bug fix. > > I will soon bump master to 1.8 release numbers. And fairly soon, we'll remove > C++03 support from master, because 1.8 will be C++ >= 11 only. No more > dragging it out. If you require C++03, then, you need to stick to something > on the RB-1.7 branch (which should continue to actively get bug fixes and the > occasional safe new feature for many months, and will remain compilable with > C++03). > > > >> On Sep 13, 2016, at 11:59 PM, Larry Gritz <[email protected]> wrote: >> >> OIIO is now branched, RB-1.7, and tagged as Release-1.7.5beta. >> >> If you have been using 1.6 releases exclusively, now is the time to ensure >> that you can build and use 1.7 before it is final. My goal is to tag an >> official release on 1 October (probably with a couple release candidates >> along the way), at which point this will be the official stable production >> branch and 1.6 will be updated only as needed for critical bug fixes. >> >> I consider 1.7's public APIs to now be locked down, though there's a tiny >> bit of wiggle room as long as we're calling it a "beta." But once we're into >> release candidates, I hope to never break link compatibility again for the >> life of 1.7.x. But we'll backport fixes and some enhancements as long as >> they don't break compatibility or seem risky. >> >> This may be called "beta", but in fact this code has been through the trials >> of production all along, with many films relying on it day in and day out. >> Unless we recently introduced bug in the last couple checkins, it is >> expected to be rock-solid and production-ready. >> >> The 'master' branch is now in-development 1.8. It will diverge from the 1.7 >> beta as soon as there is something to add to it that we deem unwise to put >> in 1.7. >> >> The 1.7 family of releases will be the last to build under both C++03 and >> C++11, and I'm planning to enforce that by requiring C++11 for 1.8 to build >> in the very near future. I also anticipate bumping some other build >> requirements, including a minimum of OpenEXR 2.2 and Boost 1.55 (these were >> the the VFX Platform standards as far back as 2015, so should certainly be >> safe for an OIIO that won't be a stable production release until some time >> in 2017, right?). >> >> -- >> 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 -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
