Build Master: Scheduling

Brad Roberts braddr at puremagic.com
Wed Nov 13 20:06:54 PST 2013


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.




More information about the Digitalmars-d mailing list