On Fri, Jan 04, 2013 at 08:18:52AM -0800, Jonathan M Davis wrote: > On Friday, January 04, 2013 15:26:20 deadalnix wrote: [...] > > Let's get a very practical case here. 2.061 have been released, and > > Kenji already fixed a bug in it (unreachable statement issue). > > > > Some people (including me, but I'm not the only one) would be > > interested by a new revision of dmd with that fix. > > > > It is why the proposal include branches as 2.N and revision as > > 2.N.M . So the same version of D, with bugfixes can be published. > > > > The branch has a 2.N form, the tag has a 2.N.M form. > > And why would that particular bug get a release as opposed to another?
It doesn't. It just gets merged in to the 2.N branch post-release, and once enough fixes have accumulated, we make a 2.N.M release. > Why wouldit be special? Or are you proposing that we do a 2.N.M > release for every bug fix? That seems insane. Some bugs are important enough to push out to the release branch, e.g. regressions or blocker bugs. Nobody is suggesting we make a new release for *every* bugfix pushed to the release branch -- that *would* be insane. The release manager, whoever that person is, makes the judgment call on when a release branch has enough bugfixes to warrant another 2.N.M release. That can be just a single bug, if it's a critical blocker bug, or it can be 20 bugs, if none of them are too important, but, taken together, constitute a significant improvement over the original release. > Why wouldn't you just use master if you want the latest? Because master potentially has breaking changes that one may not want to deal with. E.g. property enforcement, or breaking syntax changes, etc.. Enterprises who adopt D will want to stay with a stable release that won't randomly break code all over the place just because a particular bugfix was needed. That's why it's important to push regressions and blockers to release branches, without the new features in master. T -- Doubt is a self-fulfilling prophecy.