Hi all,<div><br></div><div>I know this issue has been discussed over and over again, but I'd like to voice my opinion while 3.0 is still fairly early-ish in the pipeline.</div><div><br></div><div>So the issue is... API breakage. I understand and agree with the rationale why, namely faster development. But this principle should mean that for each breakage, the dude who makes the breakage should accompany the final commit (or something like that) with a *detailed* explanation about how to migrate existing codebases, relative to the previous LLVM release. </div>
<div><br></div><div>Fact is, the release document that explains the changes is not very useful for figuring out how to upgrade between releases. </div><div><br></div><div>I literally have to wade through tons of commits and mailing list postings for each release. I gave up on that a while ago and therefore use the outdated (and not bugfree) 2.5 release (!)</div>
<div><br></div><div>I'm a front end developer and only have time for the front end and a tiny bit of back end probing. With lacking release docs and no stable dot release scheme, things are getting rather frustrating. I'm thinkering about using the more stable C wrapper, but that's pretty lame given the fact that my compiler is written in C++.</div>
<div><br></div><div>I don't really buy the manpower argument. Updating the release doc when breaking the frigging API is the Right Thing To Do and shouldn't take that long, when done when the change is fresh in memory.</div>
<div><br></div><div>This is my only gripe with llvm, but it's a pretty big one. The lack of stable releases is a slightly lesser one, but in that case, I totally buy the manpower argument.</div><div><br></div><div>Thanks for listening.</div>
<div><br></div>