[LLVMdev] RFC: Bug fix releases for 3.3 and beyond

[Sean Silva]

On Wed, Apr 3, 2013 at 1:51 PM, David Chisnall
<David.Chisnall at cl.cam.ac.uk>wrote:

> On 3 Apr 2013, at 18:42, Sean Silva <silvas at purdue.edu> wrote:
>
> > I'm not sure how difficult it actually is to follow ToT compared to one
> huge pain when upgrading for our full releases. I think it would be
> valuable to obtain feedback from projects that rely on LLVM as to how they
> go about integrating LLVM into their project and how our releases (and
> potentially dot-releases) would integrate into their development process.
>
> In FreeBSD, we ship the release with our release builds and periodically
> pull in head snapshots from time to time into head.  We occasionally
> cherry-pick fixes if they address problems that have been encountered by
> us, and we have some out-of-tree changes (although we're trying to minimise
> that).
>
> In another project, we end up with big tangles of #ifdefs to work around
> API changes (some of which are for useful improvements, many of which are
> just gratuitous churn, but that's another story) and try to track ToT where
> possible, because it minimises the headaches when a new release is
> branched.  In theory, we have working code for the new release, and we can
> just delete #ifdef branches when we drop support for another branch.
>

Thanks, this is useful to know. I have been wanting to write some
documentation about various "established patterns" of effectively
integrating LLVM into long-lived projects, as guidance for prospective
users. Would you say that these patterns effectively cope with LLVM's
idiosyncrasies? Or do you feel that they are inadequate and are actively
looking for a "better way"?

So my impression from your description is that dot-releases would not be of
much immediate use to your development process?

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130403/0d2e9d7c/attachment.html>