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