Build Master: Scheduling

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Tue Nov 19 02:34:25 PST 2013


On 14/11/13 01:37, Tyro[17] wrote:
> Major releases (2.0)
>      The big ones, every six months, intended to ship in distributions and to be
> used by stability-oriented users.
>
> Release Candidates (2.065rc1)
>      Created one to two weeks before the release branch is created, this is a
> preview of the major release. There should be very few, if any changes from the
> release candidate to the major release.
> Bugfix releases (2.064.1)
>      Based on the previous major release or bugfix; contains only bugfixes and
> perhaps documentation corrections.
>
> Beta release (2.065beta1)
>      Created monthly from master, except for those months in which we create a
> major release. Stable and suitable for users who want the latest code and can
> live with changes from month to month.
>
> Your thoughts and concerns please.

** 1 **
It might be a good idea to consider this from an alternate angle -- different 
user needs.  You can probably divide these into three groups:

     (1) I want stability above all, no updates, only bugfixes.

     (2) I want to receive new non-breaking functionality as well as bugfixes.

     (3) I want bleeding-edge everything, I can cope with backwards-incompatible
         changes.

It's not clear to me how (2) is addressed in your proposal.  What guarantees are 
made about the beta releases and backwards compatibility?  Can we assume that 
with beta releases breaking changes are always a possibility?

I imagine it may be difficult to separate out breaking and non-breaking new 
functionality in DMD development, so I can understand if you just want to 
support (1) and (3).


** 2 **
Is this proposal for DMD only, or does it include druntime and Phobos?  Either 
way there needs to be some consideration that druntime and Phobos need different 
approaches from DMD itself.  For Phobos in particular there seems to me to be 
much more short-term need for new functionality which does _not_ include 
breaking changes.


** 3 **
What's the plan for interacting with downstreams (GDC, LDC and potentially 
others)?  A 1-month beta turnaround may be too fast for them to do the work of 
integrating new releases; 6 months is an awfully long time to wait for updates.

Speaking as one who relies on the speed of the executables they produce, I would 
be quite upset if I had to wait 6 months for Phobos updates with these compilers 
-- it's already been frustrating enough as it is having to wait 3+ months for 
them to get Phobos bugfixes that I've provided.


More information about the Digitalmars-d mailing list