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.
