Next focus: PROCESS

[H. S. Teoh]

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.