Breaking D2 language/spec changes with D1 being discontinued in a month

[H. S. Teoh]

On Thu, Nov 29, 2012 at 08:08:08PM +0100, Joseph Rushton Wakeling wrote:
> On 11/28/2012 08:02 PM, 1100110 wrote:
> >A new module in Phobos is highly unlikely to break anything, So I
> >would assume that this would count as a simple bug fix and be merged.
> 
> I don't really see that.  Yes, new functionality _per se_ is not going
> to break anything, but its implementation may be affected by breaking
> changes to D.  So, if you want to bring something new to Phobos, you
> may have to write 2 variants (for stable and dev) or else put up with
> your new functionality being excluded from stable until the breaking
> changes to D are merged in.

Isn't this only necessary if the new feature depends on said breaking
changes? If not, it can be safely merged in. If it's a trivial change
like a syntax change, the stable maintainer can simply fix it by hand
and merge it in anyway.

The way I see it, is that after each release cycle, master is frozen for
beta testing, bugs are fixed, then master becomes the new stable (say,
by making a stable branch off the current master), then development
continues on master (apart from the new stable). Then there's no need to
reconcile any tweaks previously made to the previous stable branch,
since those will be distinct from the new stable.

If we do it this way, we can have actual, maintainable release branches.
For example:

(This is a hypothetical timeline:)
2013 Jan: master is deemed stable enough to be released, so we make a
new stable branch, call it stable-2.061. New development work continues
on master.

2013 Mar: new features are added to master. Stable maintainer decides
those changes are non-breaking and safe to merge in, so he cherry-picks
the changes and puts them into stable-2.061.

2013 Apr: breaking changes are made to master. Stable maintainer decides
*not* to pull them into stable-2.061.

2014 Jun: master is deemed almost ready for next release. Code is frozen
and extensive testing is done. Stable maintainer cherry-picks most
important fixes and backports them to stable-2.061.

2014 Jul: master is deemed releasable. Stable maintainer makes a new
branch from master, stable-2.062. New development continues on master.
The previous stable branch stable-2.061, is retired, or put in
maintenance mode (no longer actively maintained, but if there's a
critical fix in master that people are clamoring for, somebody can
cherry-pick those and put them in -- after making sure it's
non-breaking, of course).

etc..

The important thing to note here is that Walter & co. only ever works on
master. Whoever maintains the stable branches makes the decisions on
what to cherry-pick from master to put in the stable branch(es). (It
doesn't have to be exclusive, of course, ideally he would garner some
consensus on what should be included, but the point is that the core
developers shouldn't even have to worry about what goes into the stable
branches, they just work on master.)


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs