On Wed, Dec 19, 2012 at 02:01:57PM -0500, Andrei Alexandrescu wrote: > On 12/19/12 1:45 PM, H. S. Teoh wrote: > >On Fri, Dec 14, 2012 at 10:16:45AM -0500, Andrei Alexandrescu wrote: > >>On 12/14/12 10:02 AM, H. S. Teoh wrote: > >>>A number of us have put up a draft of a proposed release process on > >>>the wiki, based on some of the things discussed in this thread. > >>> > >>> http://wiki.dlang.org/Release_Process > >> > >>Seen it, will give a thorough read today. Thanks! > >[...] > > > >Just to follow up, any comments on what's there currently? > > > >I fear that some of us on this thread may be over-engineering the > >whole thing without input from the core devs who will actually be > >implementing this process. > > I was hoping for more consensus to build in this thread. Right now > it seems there's still quite a bit of controversy about what the > best way to go is. [...]
I think we need more input from the core devs before any further discussions make sense. Like deadalnix said, we've gone way overboard with the over-engineering; can we at least get the core devs to evaluate the most basic tenets of the proposal first? Others can correct me if I'm wrong, but the main points as I understand them are: - Continue using master for development, as before. - New features will be developed in their own dedicated branches (branched from master), NOT on master directly. When the new feature is deemed ready, by some criterion to be decided on, then it's merged into master. - At some point in the process, perhaps after a release is made from staging (see below), the new changes in master are folded into the staging branch (we can argue about the exact name of this later). - The intent of staging is to test new features and possibly breaking changes by a wider audience before the official release. It is to be used by people who want bleeding-edge features and can live with existing code breaking once in a while. - Staging only receives bugfixes and no new features until it's deemed release-ready. It may receive breaking changes if a particular feature is deemed unsuitable in its present form and needs to be revised. (Said changes are also applied to master, of course.) This is where new features are refined from their initial design to their final form. - Once staging is release-ready, a release branch is made from staging, then the latest stuff from master is folded into staging. - A release branch is used for applying critical bugfixes and showstopper fixes after a release is made. It does not receive low-priority bug fixes, and certainly no new features and no breaking changes. I deliberately left out things like version numbering and timelines, etc., as those are just bikeshedding. The exact criteria under which master is folded into staging, and staging is deemed release-ready, are intentionally left vague. We need the core devs to evaluate whether these high-level steps in the process are actually workable first, before we even think about timelines, version numberings, and merging/branching criteria. T -- All problems are easy in retrospect.