Hi all, 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. 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. Fact is, the release document that explains the changes is not very useful for figuring out how to upgrade between releases. 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 (!) 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++. 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. 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. Thanks for listening. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110713/a80916e7/attachment.html>
On 13 July 2011 15:47, fly language <flylanguage at gmail.com> wrote:> 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.I regularly make small API-breaking changes in the name of cleaning things up. Sorry! I'd be happy to update the release notes if folks reckon this is the right thing to do. Would it just mean adding a <ul> to the (currently empty) list in docs/ReleaseNotes.html#api_changes ? Jay.
I would like to second the request, I got tripped up when migrating from 2.8 to 2.9 w.r.t. many of the changes in pass initialization/registration. On Wed, Jul 13, 2011 at 9:09 AM, Jay Foad <jay.foad at gmail.com> wrote:> On 13 July 2011 15:47, fly language <flylanguage at gmail.com> wrote: >> 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. > > I regularly make small API-breaking changes in the name of cleaning > things up. Sorry! I'd be happy to update the release notes if folks > reckon this is the right thing to do. Would it just mean adding a <ul> > to the (currently empty) list in docs/ReleaseNotes.html#api_changes ? > > Jay. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Jul 13, 2011, at 8:09 AM, Jay Foad wrote:> On 13 July 2011 15:47, fly language <flylanguage at gmail.com> wrote: >> 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. > > I regularly make small API-breaking changes in the name of cleaning > things up. Sorry! I'd be happy to update the release notes if folks > reckon this is the right thing to do. Would it just mean adding a <ul> > to the (currently empty) list in docs/ReleaseNotes.html#api_changes ?Sure, that makes perfect sense. -Chris
On 07/13/2011 05:09 PM, Jay Foad wrote:> I regularly make small API-breaking changes in the name of cleaning > things up. Sorry! I'd be happy to update the release notes if folks > reckon this is the right thing to do. Would it just mean adding a<ul> > to the (currently empty) list in docs/ReleaseNotes.html#api_changes ?That's definitely needed. Not every LLVM user tracks development on trunk very closely and reads every commit message. A quick note about the nature of API-breaking changes and a hint on how to migrate existing sources would be really appreciated. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag