Next focus: PROCESS

[Joseph Rushton Wakeling]

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.