521 days, 22 hours, 7 minutes and 52 seconds...

[aldanor via Digitalmars-d]

On Tuesday, 27 January 2015 at 09:07:30 UTC, tn wrote:
> On Monday, 26 January 2015 at 20:35:31 UTC, Andrei Alexandrescu
> wrote:
>> On 1/26/15 12:30 PM, Dicebot wrote:
>>> We couldn't merge it into std.experimental before because you 
>>> have
>>> stated that even std.experimental modules shouldn't have a 
>>> breaking
>>> changes normally. It was 2 reviews ago.
>>>
>>> Now you have reconsidered, which is understandable 
>>> considering how long
>>> has it been taking, but pretending that was intended to work 
>>> that way
>>> does not make you look good :(
>>>
>>> PS I was in favor for very lax initial requirements for 
>>> experimental
>>> packages for this very reason.
>>
>> Now I remember. I admit I was wrong. -- Andrei
>
> I thought the idea was that there should be no _known_ pending
> breaking changes when mergin into std.experimental. Thus
> std.experimental would be for fixing problems that are found 
> when
> the package is actually used. Breaking changes for fixing those
> would be perfectly fine.
>
> 1. review => if problems found => fix all known problems and
> repeat the review
> 2. once everyting seems ok in review => merge to 
> std.experimental
> 3. if a new problem requiring a breaking change is found => fix 
> it
> 4. once no new problems have been found for a while => seems ok
> => merge to std
> 5. if a new problem requiring a breaking change is found => 
> can't
> fix it, maybe try to cirmumvent it somehow etc. (no breaking
> changes unless it's critical)

I found out I quite like the Rust's way of doing this because 
it's changing so much and so fast -- plain and simple, unstable 
features are put behind "feature gates" and the only way for the 
end user to use unstable API is to explicitly mark it as allowing 
the unstable code. This also goes well with RFC review process. 
Once the feature is stabilized, no changes to user code are 
required, no imports to be changed etc. This allows them to merge 
in ridiculous amount of PRs/day and test everything out live 
without affecting the core stable API.