On 02/18/2015 04:57 PM, Renato Golin wrote:> On 18 February 2015 at 21:45, Tom Honermann <thonermann at coverity.com> wrote: >> Unfortunately, we don't currently have the resources to do so. When we >> upgrade, we upgrade to the most recent release and perform testing on top of >> it. > > One safe way of doing so, and would help us without adding much > efforts to you guys, would be to do that on every major release (*.0), > report *any* bug, and collect the fixes on the subsequent > dot-releases.I would love to do that. Unfortunately, I'm not the one paying the bills :) (I do, and will continue to, lobby my management to keep current and ensure we report defects and fixes). The effort isn't always so small for us however. It has generally taken us about a month to upgrade and vet a new Clang release. The Clang release cadence is faster than ours, so timing isn't always great (not a complaint, just a reality). Before we upgrade again, we also have to port our internal code and build systems to C++11 since Clang now requires that (again, not a complaint, I'm glad to see Clang using new language features!)> This way, you only upgrade to dot-releases, where the compiler is more > stable and API changes are forbidden. If you mark the most important > bugs from the major tests as critical to the next dot release, the > probability that it'll be fixed and back-ported is very high.Yes, this is pretty much our strategy. I've been very happy to see the dot releases being done.>> Having such issues fixed prior >> to the release would be a benefit to us. We don't expect the releases to be >> perfect. > > The proposal above would be a good compromise to both of us. :)I agree. Tom.
On 19 February 2015 at 19:58, Tom Honermann <thonermann at coverity.com> wrote:> The effort isn't always so small for us however. It has generally taken us > about a month to upgrade and vet a new Clang release. The Clang release > cadence is faster than ours, so timing isn't always great (not a complaint, > just a reality).That's why most developers keep in sync with ToT. It hurts a lot less than yearly migrations, even if you only release your software once a year. And you can still rely on release tests as a point-in-time of stability.> Before we upgrade again, we also have to port our internal > code and build systems to C++11 since Clang now requires that (again, not a > complaint, I'm glad to see Clang using new language features!)Yeah, the C++11 will sting a bit. cheers, --renato
On 02/19/2015 04:28 PM, Renato Golin wrote:> On 19 February 2015 at 19:58, Tom Honermann <thonermann at coverity.com> wrote: >> The effort isn't always so small for us however. It has generally taken us >> about a month to upgrade and vet a new Clang release. The Clang release >> cadence is faster than ours, so timing isn't always great (not a complaint, >> just a reality). > > That's why most developers keep in sync with ToT. It hurts a lot less > than yearly migrations, even if you only release your software once a > year. And you can still rely on release tests as a point-in-time of > stability.It hurts less at one time, yes. But syncing often is actually more costly due to overhead involved with each sync, at least for us. We aren't in a position to just merge ToT, try a build, and see what happens due to various automated build required integration processes. Not your concern though :) Tom.
Seemingly Similar Threads
- [LLVMdev] [cfe-dev] [3.6 Release] RC3 has been tagged
- [LLVMdev] [cfe-dev] [3.6 Release] RC3 has been tagged
- [LLVMdev] [cfe-dev] [3.6 Release] RC3 has been tagged
- [LLVMdev] Patch to enable LLVM to build successfully with shared library support disabled
- [LLVMdev] [cfe-dev] [3.6 Release] RC3 has been tagged