Build Master: Scheduling

[Tyro[17]]

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");
}