llvm dev - Feb 2013 - [LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API

Bill Wendling <wendling at apple.com> writes:

[snip]
> Welcome to living on the top-of-tree! :-)
>
> We are in between releases. It's expected that the APIs will be
> unstable. [snip]
One thing is an unstable API, and a different thing is a code base where
an API change is introduced gradually. From the POV of users, the latter
is more like a pre-alpha stage API.

Using development branches would lessen the problem: you work on your
branch until you are happy with the API, then merge the changes into
trunk. When you are the only one working on the task, it is very easy to
do using git-svn.

As for living on the top-of-tree: with the development model of LLVM it
is desirable that as much users as possible work with ToT, because the
bug reports those users contribute. (And, what is the standard response
when somebody finds a bug on a released version? "upgrade to ToT") So
you don't want to scare away people from working with ToT.

On Feb 6, 2013, at 2:02 AM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> Bill Wendling <wendling at apple.com> writes:
> 
> [snip]
> 
>> Welcome to living on the top-of-tree! :-)
>> 
>> We are in between releases. It's expected that the APIs will be
>> unstable. [snip]
> 
> One thing is an unstable API, and a different thing is a code base where
> an API change is introduced gradually. From the POV of users, the latter
> is more like a pre-alpha stage API.
> 
> Using development branches would lessen the problem: you work on your
> branch until you are happy with the API, then merge the changes into
> trunk. When you are the only one working on the task, it is very easy to
> do using git-svn.
> 
> As for living on the top-of-tree: with the development model of LLVM it
> is desirable that as much users as possible work with ToT, because the
> bug reports those users contribute. (And, what is the standard response
> when somebody finds a bug on a released version? "upgrade to
ToT") So
> you don't want to scare away people from working with ToT.
Using a development branch and then slamming those changes into trunk is at odds
with the llvm style incremental development philosophy. Living on ToT isn't
easy. No one ever said it would be. The changes that are being complained about
have only been happening for about a week now. And they're more stable day
by day.

-bw

Bill Wendling <wendling at apple.com> writes:
> Using a development branch and then slamming those changes into trunk
> is at odds with the llvm style incremental development philosophy.
In this case, the LLVM incremental style is counterproductive, for both
users and developers. Who is interested on watching your API going
through intermediate stages and (possibly) experimental points until it
stabilizes?
> Living on ToT isn't easy. No one ever said it would be.
This is no reason for ignoring practices that can improve the
experience.
> The changes that are being complained about have only been happening
> for about a week now.
I have several modifications on my code base that go back until past
June for adapting to changes on the attributes API. But that's not the
point. I'm not thinking about your specific case, but on the general
one.
> And they're more stable day by day.
You are proving my point. It is a waste to use trunk for things that are
considered by the author to be on work-on-progress state. That only
creates noise for both developers and users, without any advantage for
the author. Work on a feature branch and merge the changes when you are
happy with your code.