[cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

[Richard Smith]

On Tue, Oct 29, 2013 at 6:11 PM, "C. Bergström" <cbergstrom at pathscale.com>wrote:

> On 10/30/13 03:17 AM, Chandler Carruth wrote:
>
>> On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" <cbergstrom at pathscale.com<mailto:
>> cbergstrom at pathscale.**com <cbergstrom at pathscale.com>>> wrote:
>>
>>     On 10/29/13 07:27 AM, Chandler Carruth wrote:
>>
>>         On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström"
>>         <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.**com<cbergstrom at pathscale.com>
>> >
>>         <mailto:cbergstrom at pathscale.**com <cbergstrom at pathscale.com>
>>
>>         <mailto:cbergstrom at pathscale.**com <cbergstrom at pathscale.com>>>>
>> wrote:
>>
>>             fuzzy://How much "heads up"
>>
>>
>>         One full release cycle, so approximately 6 months before a release
>>
>>     If it's 3-6 months from *today* before something hits clang svn
>>     trunk that should be enough time to address any problems.
>>
>>
>> No, it's 1 month, maybe 2 before something hits trunk, and over 6 months
>> before something hits a release.
>>
> I'm objecting to 1 month for svn trunk - 2 months notice is even pushing
> it imho.
>
> 1) This is imho not the small change which it's being presented as
> 2) As someone else stated - there are projects tracking svn trunk and
> telling them to just stop doing that and follow the previous release is
> untenable without sufficient notice. (It just doesn't seem fair)
>

If such projects exist and don't want to switch to C++11 mode, I think we
should let them speak up, and not delay our own plans on the hypothesis
that they exist. (Maybe they'll say that this is sufficient notice, maybe
not, but we can't really guess.)


> May I humbly propose you create a c++11-development branch
> now/later/anytime and let people start using that. In parallel to that let
> people know that pieces of the c++11 branch will potentially start merging
> Feb 1st 2014. (roughly 3 months from today). This gives people time to
> review things before they hit trunk, test, discuss and experiment in a way
> that virtual discussions simply can't flush out. This hopefully won't hurt
> your target of the release-after-next using more modern toolchains and is
> *hopefully* a win-win in your view.


I don't see how this helps anything. We don't /want/ to have the hassle of
some people developing on a branch and some on trunk, so we would
essentially have trunk stagnating and everyone developing on the branch.
And then we'd merge the branch back again. Net result: exactly the same as
if the people who aren't ready for c++11 stick with the 3.4 release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131029/103db8b2/attachment.html>