Next focus: PROCESS

[RenatoUtsch]

On Thursday, 13 December 2012 at 15:44:25 UTC, Joseph Rushton 
Wakeling wrote:
> On 12/13/2012 10:07 AM, Jonathan M Davis wrote:
>> That makes a _lot_ more sense than the unstable => testing => 
>> stable model.
>>
>> I like the idea of having an LTS release at some interval 
>> (probably 1 year)
>> where that branch has bug fix releases more or less monthly. 
>> We then have a dev
>> release cycle where we put out a version of the master branch 
>> every 2 or 3
>> months or so, where it includes whatever new features we want 
>> to include but
>> haven't been merged into the LTS branch yet. Then with the 
>> next major LTS
>> release, we merge in all of the new stuff from the master 
>> branch so that it's
>> essentially up to date with master (possibly modulo some newer 
>> features or
>> other major changes if they weren't deemed ready yet).
>
> I wonder if I maybe created some confusion by conflating "LTS" 
> and "stable" -- I don't think I should really have done that.
>
> The problem that I see with what you describe is that it gives 
> no clear mechanism for how breaking changes should be handled 
> -- I don't mean the decision-making process of "Should we make 
> this change?" but the means in which users are supported in 
> making the shift from one LTS to another.
>
> So, perhaps it would help if I proposed instead:
>
>    -- A _stable_ release is what we all understand, a release 
> that has been
>       properly tested and has no outstanding bug reports at the 
> time of first
>       release, and to which only bugfixes are subsequently made
>
>    -- LTS should refer to a _cycle_ of stable releases within 
> which no breaking
>       changes are made
>
>    -- Successive LTS cycles should overlap so that the previous 
> cycle is still
>       receiving bugfixes for some time after the new LTS cycle 
> begins.  In this
>       way, users have a safe period in which to update their 
> codebases to the
>       new LTS.
>
> So -- forgetting D's versioning scheme for a moment -- suppose 
> you label a given LTS cycle with N.  Then N.0, N.1, N.2, ... 
> would be the stable releases containing new but non-breaking 
> features, which might be made annually, or every 6 months.  
> N.x.0, N.x.1, N.x.2, ... would be the bugfix-only updates to 
> those releases, made as often as necessary.
>
> Once LTS cycle N+1 has begun, then you stop making N.x releases 
> and only apply further bug fixes.  Likewise, bugfixes to N.x 
> stop getting released once N.x+1 is released.
>
> So, if you assume a stable release annually, and that an LTS 
> cycle lasts 3 years, you might have:
>
> 1st year    N.0.0
>                 - N.0.1   [bugfixes]
>                 - N.0.2
>                   ...
>
> 2nd year    N.1.0   [non-breaking new features]
>                 - N.1.1
>                 - N.1.2
>                   ...
>                                          [new LTS cycle begins, 
> maybe with
>                                           breaking changes]
> 3rd year    N.2.0                       N+1.0.0
>                 - N.2.1                       - N+1.0.1
>                 - N.2.2                       - N+1.0.2
>                   ...                           ...
>
> 4th year    N+1.1.0    [entirely moved over to new LTS]
>                   - N+1.1.1
>                   - N+1.1.2
>                     ...
>
> 5th year    N+1.2.0                     N+2.0.0 [new LTS begins]
>
> 6th year    N+2.1.0
>
> 7th year    N+2.2.0                     N+3.0.0
>
>             ... etc.
>
> Of course, the timeline could be altered but the point would be 
> that for every LTS cycle you'd have up to a year in which to 
> switch, and _within_ every LTS cycle you would receive stable 
> updates with bugfixes (regularly) and well-tested new features 
> (annually, 6-monthly?).
>
> That's surely more work for developers but is probably worth it 
> in terms of security for users of D.  In the event that a new 
> LTS is accompanied by no breaking changes, you might do away 
> with the year's overlap to save the extra work.
>
> If you want to translate the above into actual D version 
> numbers, you could do it in the form V.N.x.y where V is the D 
> language version (2 for the foreseeable future:-), N the LTS 
> cycle, etc.
>
> That leaves out "dev" releases, but you might want to number 
> them differently anyway -- e.g. dev-YYYYmmdd or whatever.
>
>> As for the standard library and its releases, I wouldn't 
>> really expect them to
>> be decoupled from the compiler's releases but rather that they 
>> would continue
>> more or less as they have been. I think that it's too often 
>> the case that
>> changes in them need to be made at the same time for it to 
>> really work to
>> decouple them at this point.
>
> My feeling here was that as it stands Phobos is still somewhat 
> more in flux than D itself, not so much in terms of breaking 
> changes as in terms of new features being added.  So, I was 
> wondering if it might be worthwhile to make new-Phobos-feature 
> releases on a more regular basis at least in the short term 
> while the library is still being expanded.  But I won't press 
> for it too much.

This approach looks the best to D. As we have the "problem" that 
some users want to see D more stable and other users want to see 
it evolve, to not turn into what C++ has become, this approach 
looks the best solution of all that were proposed here.

It will satisfy the users that like the language to be more 
stable for serious development, while the language can still 
evolve and the language devs will be able to do the things right.

if each LTS is supported for about 5 years, and with 1 year 
supporting the last LTS after a new one is released, D will be 
stable enough for serious development, what will attract much 
people, as the language is simply incredible, the only problem 
(at least with all people I know) is that it is not really stable.

While the LTS versions are supported, breaking changes can be 
introduced in non-LTS versions that are supported for bugfixes 
for... say 6 monthes, and non-breaking changes are merged on both 
the LTS and the non-LTS.

This will satisfy all D users... it will only require more work 
from the D team.