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.
