Greetings,

I have accepted the responsibility of preparing the builds for DMD and would like to engage in conversation about the way ahead.

The first concern I have is about the build cycle. Presently, it is nonexistent. There is no rhyme or reason regarding when releases are produced. The v2.065 agenda (first attempt of its kind) suggests that the next release will occur sometime in March 2014. I'm of the opinion, however, that the cycle should be six months long. This particular schedule is not of my own crafting but I believe it to be sound and worthy of emulation:

Schedule
--------

2.064 --- 2.064.1 --- 2.064.2 -- ...
  \
   + -- 2.065beta1 --- 2.065beta2 --- ... --- 2.065rc1 --- 2.065 --- 2.065.1 --- ...
                                                            \
                                                              + -- 2.066beta1 --- ...

Starting from the date of a major release (November 5th):

At four-week intervals we make a new beta release. There will be no separate release candidate, but if a serious problem is discovered we may do the next beta ahead of schedule or make a point release. There will be about five or six releases in that series.

In parallel with this, bugs targeted to the previous major release are merged into its branch. We will make bugfix releases from that branch as appropriate to the accumulation of changes, perhaps monthly, perhaps more often if there are serious bugs, perhaps much less often if no new changes have landed.

We will then make a release candidate for the next major release, and at this point create a release branch for it. We will iterate release candidates at approximately weekly intervals until there are no bugs blocking the final major release.

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.

-- 

Andrew Edwards
--------------------
http://www.akeron.co
auto getAddress() {
    string location = "@", period = ".";
    return ("info" ~ location ~ "afidem" ~ period ~ "org");
}

On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
> Greetings,
>
> I have accepted the responsibility of preparing the builds for DMD and would like to engage in conversation about the way ahead.
>
> The first concern I have is about the build cycle. Presently, it is nonexistent. There is no rhyme or reason regarding when releases are produced. The v2.065 agenda (first attempt of its kind) suggests that the next release will occur sometime in March 2014. I'm of the opinion, however, that the cycle should be six months long. This particular schedule is not of my own crafting but I believe it to be sound and worthy of emulation:
>
> Schedule
> --------
>
> 2.064 --- 2.064.1 --- 2.064.2 -- ...
>   \
>    + -- 2.065beta1 --- 2.065beta2 --- ... --- 2.065rc1 --- 2.065 --- 2.065.1 --- ...
>                                                             \
>                                                               + -- 2.066beta1 --- ...
>
> Starting from the date of a major release (November 5th):
>
> At four-week intervals we make a new beta release. There will be no separate release candidate, but if a serious problem is discovered we may do the next beta ahead of schedule or make a point release. There will be about five or six releases in that series.
>
> In parallel with this, bugs targeted to the previous major release are merged into its branch. We will make bugfix releases from that branch as appropriate to the accumulation of changes, perhaps monthly, perhaps more often if there are serious bugs, perhaps much less often if no new changes have landed.
>
> We will then make a release candidate for the next major release, and at this point create a release branch for it. We will iterate release candidates at approximately weekly intervals until there are no bugs blocking the final major release.
>
> 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.

Awesome. That is perfect.

On 11/13/13 4:37 PM, Tyro[17] wrote:
> I'm of the opinion, however, that
> the cycle should be six months long. This particular schedule is not of my own crafting but I
> believe it to be sound and worthy of emulation:

I think 6 months between releases is entirely too long.  I'd really like us to be back closer to the once every month or two rather than only twice a year.  The pace of change is high and increasing (which is a good thing).  Release early and often yields a smoother rate of introducing those changes to the non-bleeding-edge part of the community.  The larger the set of changes landing in a release the more likely it is to be a painful, breaking, experience.

> Schedule
> --------
>
> 2.064 --- 2.064.1 --- 2.064.2 -- ...
>    \
>     + -- 2.065beta1 --- 2.065beta2 --- ... --- 2.065rc1 --- 2.065 --- 2.065.1 --- ...
>                                                              \
>                                                                + -- 2.066beta1 --- ...

As drawn, this looks a lot like a branch structure rather than release timing.  I dearly hope this isn't intended to represent branching.

My few cents,
Brad

On Thursday, 14 November 2013 at 02:47:15 UTC, Brad Roberts wrote:
> I think 6 months between releases is entirely too long.  I'd really like us to be back closer to the once every month or two rather than only twice a year.  The pace of change is high and increasing (which is a good thing).  Release early and often yields a smoother rate of introducing those changes to the non-bleeding-edge part of the community.  The larger the set of changes landing in a release the more likely it is to be a painful, breaking, experience.

I agree. There's really no reason not to release frequently as long as the release process isn't overly burdensome on the Release Czar (Walter's term, not mine :P). Git's cheap and powerful branching means it's easy to work on changes of nearly any size and still have a rapid release cycle.

6 months between releases means a regression that was introduced in the latest version requires you to wait another 6 months for the fix which means you are running a version that is a year out of date.

On 11/13/13, 9:46 PM, Brad Roberts wrote:
> On 11/13/13 4:37 PM, Tyro[17] wrote:
>> I'm of the opinion, however, that
>> the cycle should be six months long. This particular schedule is not
>> of my own crafting but I
>> believe it to be sound and worthy of emulation:
>
> I think 6 months between releases is entirely too long.  I'd really like
> us to be back closer to the once every month or two rather than only
> twice a year.  The pace of change is high and increasing (which is a
> good thing).  Release early and often yields a smoother rate of
> introducing those changes to the non-bleeding-edge part of the
> community.  The larger the set of changes landing in a release the more
> likely it is to be a painful, breaking, experience.

Surely for those of us that live on the edge, it is fun to be able to use the latest and greatest. Hence the reason for monthly release of betas. Within a month (sometimes shorter) of any new feature being implemented in the language, you'll be able to download the binaries for your favorite distro and begin testing it.

The side effect is that there is more time to flesh out a particular implementation and get it corrected prior to it being an irreversible eyesore in the language. You also have a greater play in the filing bug reports as to aid in minimizing the number of bugs that make it into the final release.

Unlike us adventurers however, companies require a more stable environment to work in. As such, the six month cycle provides a dependable time frame in which they can expect to see only bugfixes in to the current release in use.

I think this release plan is a reasonable compromise for both parties.

>> Schedule
>> --------
>>
>> 2.064 --- 2.064.1 --- 2.064.2 -- ...
>>    \
>>     + -- 2.065beta1 --- 2.065beta2 --- ... --- 2.065rc1 --- 2.065 ---
>> 2.065.1 --- ...
>>                                                              \
>>                                                                + --
>> 2.066beta1 --- ...
>
> As drawn, this looks a lot like a branch structure rather than release
> timing.  I dearly hope this isn't intended to represent branching.

This is in no way intended to represent branching. Simply to indicate that while betas are being released for the upcoming release, it may at times be necessary to release bug fixes.

> My few cents,
> Brad
>


-- 

Andrew Edwards
--------------------
http://www.akeron.co
auto getAddress() {
    string location = "@", period = ".";
    return ("info" ~ location ~ "afidem" ~ period ~ "org");
}

On Thursday, 14 November 2013 at 03:03:14 UTC, Brad Anderson
wrote:
> On Thursday, 14 November 2013 at 02:47:15 UTC, Brad Roberts wrote:
clip
>
> 6 months between releases means a regression that was introduced in the latest version requires you to wait another 6 months for the fix which means you are running a version that is a year out of date.

Don't the point releases on the main branch effectively deal with
this issue?

Craig

On 11/13/13, 10:03 PM, Brad Anderson wrote:
> On Thursday, 14 November 2013 at 02:47:15 UTC, Brad Roberts wrote:
>> I think 6 months between releases is entirely too long.  I'd really
>> like us to be back closer to the once every month or two rather than
>> only twice a year.  The pace of change is high and increasing (which
>> is a good thing).  Release early and often yields a smoother rate of
>> introducing those changes to the non-bleeding-edge part of the
>> community.  The larger the set of changes landing in a release the
>> more likely it is to be a painful, breaking, experience.
>
> I agree. There's really no reason not to release frequently as long as
> the release process isn't overly burdensome on the Release Czar
> (Walter's term, not mine :P). Git's cheap and powerful branching means
> it's easy to work on changes of nearly any size and still have a rapid
> release cycle.
>
> 6 months between releases means a regression that was introduced in the
> latest version requires you to wait another 6 months for the fix which
> means you are running a version that is a year out of date.

Not so. The very reason for bugfix releases is to ensure that critical fixes are provided as quickly as feasible.

On the other hand you will have six months to prod and poke at the betas to ensure that the impending release is void of bugs. And with a monthly release of betas, the opportunity to test out new features and fixes within, at most, one month after their implementation.

Again fixes can always be pushed out as bugfix releases on as frequent or infrequent a term as the situation warrants.

-- 

Andrew Edwards
--------------------
http://www.akeron.co
auto getAddress() {
    string location = "@", period = ".";
    return ("info" ~ location ~ "afidem" ~ period ~ "org");
}

On 11/13/13 7:13 PM, Tyro[17] wrote:
> On 11/13/13, 9:46 PM, Brad Roberts wrote:
>> On 11/13/13 4:37 PM, Tyro[17] wrote:
>>> I'm of the opinion, however, that
>>> the cycle should be six months long. This particular schedule is not
>>> of my own crafting but I
>>> believe it to be sound and worthy of emulation:
>>
>> I think 6 months between releases is entirely too long.  I'd really like
>> us to be back closer to the once every month or two rather than only
>> twice a year.  The pace of change is high and increasing (which is a
>> good thing).  Release early and often yields a smoother rate of
>> introducing those changes to the non-bleeding-edge part of the
>> community.  The larger the set of changes landing in a release the more
>> likely it is to be a painful, breaking, experience.
>
> Surely for those of us that live on the edge, it is fun to be able to use the latest and greatest.
> Hence the reason for monthly release of betas. Within a month (sometimes shorter) of any new feature
> being implemented in the language, you'll be able to download the binaries for your favorite distro
> and begin testing it.
>
> The side effect is that there is more time to flesh out a particular implementation and get it
> corrected prior to it being an irreversible eyesore in the language. You also have a greater play in
> the filing bug reports as to aid in minimizing the number of bugs that make it into the final release.
>
> Unlike us adventurers however, companies require a more stable environment to work in. As such, the
> six month cycle provides a dependable time frame in which they can expect to see only bugfixes in to
> the current release in use.
>
> I think this release plan is a reasonable compromise for both parties.

Companies that don't want frequent changes can just skip releases, using whatever update frequency meets their desires.  Companies do this already all the time.  That only issue there is how long we continue to backport fixes into past releases.  So far we've done very minimal backporting.

On 11/13/13, 11:06 PM, Brad Roberts wrote:
> On 11/13/13 7:13 PM, Tyro[17] wrote:
>> On 11/13/13, 9:46 PM, Brad Roberts wrote:
>>> On 11/13/13 4:37 PM, Tyro[17] wrote:
>>>> I'm of the opinion, however, that
>>>> the cycle should be six months long. This particular schedule is not
>>>> of my own crafting but I
>>>> believe it to be sound and worthy of emulation:
>>>
>>> I think 6 months between releases is entirely too long.  I'd really like
>>> us to be back closer to the once every month or two rather than only
>>> twice a year.  The pace of change is high and increasing (which is a
>>> good thing).  Release early and often yields a smoother rate of
>>> introducing those changes to the non-bleeding-edge part of the
>>> community.  The larger the set of changes landing in a release the more
>>> likely it is to be a painful, breaking, experience.
>>
>> Surely for those of us that live on the edge, it is fun to be able to
>> use the latest and greatest.
>> Hence the reason for monthly release of betas. Within a month
>> (sometimes shorter) of any new feature
>> being implemented in the language, you'll be able to download the
>> binaries for your favorite distro
>> and begin testing it.
>>
>> The side effect is that there is more time to flesh out a particular
>> implementation and get it
>> corrected prior to it being an irreversible eyesore in the language.
>> You also have a greater play in
>> the filing bug reports as to aid in minimizing the number of bugs that
>> make it into the final release.
>>
>> Unlike us adventurers however, companies require a more stable
>> environment to work in. As such, the
>> six month cycle provides a dependable time frame in which they can
>> expect to see only bugfixes in to
>> the current release in use.
>>
>> I think this release plan is a reasonable compromise for both parties.
>
> Companies that don't want frequent changes can just skip releases, using
> whatever update frequency meets their desires.  Companies do this
> already all the time.  That only issue there is how long we continue to
> backport fixes into past releases.  So far we've done very minimal
> backporting.
>
>

And what I am proposing is that we start backporting to stable releases and with subsequent bugfix releases.

I'm also suggesting that for people interested in a more frequent release will have at least five, if not more, such releases (betas) prior to the official release. Live on the edge... use the beta. That's what we do now.

At the moment there's nothing that make dmd.2.064.2 any more bug free than its previously released counterparts. Very few people participated in the review of the betas which were released arbitrarily (when the time seemed right). We simply call on of those betas dmd.2.064.2 and moved on. It still has a slew of bugs and more are discovered daily as people start to finally use the so called  "release".

I'm saying we are go about it a little different. We get more people involved in the testing process by providing more frequent release of betas and getting much of the bugs identified fixed before designating a release. To me you get what your are after a faster turnaround on fixes (monthly). And the broader customer base gets a more stable product with less bugs.

-- 

Andrew Edwards
--------------------
http://www.akeron.co
auto getAddress() {
    string location = "@", period = ".";
    return ("info" ~ location ~ "afidem" ~ period ~ "org");
}

On 11/14/13, Brad Anderson <eco@gnuk.net> wrote:
> 6 months between releases means a regression that was introduced in the latest version requires you to wait another 6 months for the fix which means you are running a version that is a year out of date.

6 months is ridiculously long. The changelog itself will have to span pages. And because a lot of people do not use DMD-head we'll end up with a ton of regressions that are only caught after a release is made. And people who want an important fix will have to wait 6 months for a release. New library features or modules will only be properly tested after a release, so that means potentially waiting 6 months with very little feedback.

IMO 6 months is unacceptably long. We're not steering an oil rig here, D is supposed to be a speedboat.