Le 14/11/2013 09:39, luka8088 a écrit :
On 14.11.2013. 5:29, Tyro[17] wrote:
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.
Just a wild thought...
Maybe we can have monthly release and still keep it stable. Imagine this
kind of release schedule:
Month # 11 12 1 2 3
2.064 2.065 2.066 2.067 2.068
2.065rc2 2.066rc2 2.067rc2 2.068rc2 2.069rc2
2.066rc1 2.067rc1 2.068rc1 2.069rc1 2.070rc1
2.067b2 2.068b2 2.069b2 2.070b2 2.071b2
2.068b1 2.069b1 2.070b1 2.071b1 2.072b1
2.069alpha 2.070alpha 2.071alpha 2.072alpha 2.073alpha
Where new features are only added to alpha release. And bug fixes are
added to all releases.
This way new bug fixes and new features would be released every month
but there would be a 5 month delay between the time that feature A is
added to the alpha release and the time feature A is propagated to the
stable release. But during this period feature A would be propagated
through releases and there would be plenty of opportunity to test it and
clear it of bugs. I am not a fan of such delay but I don't see any other
way new features could be added without higher risk of bugs.
Also vote up for daily snapshots.
As pure D user, I am not really comfortable with having to wait 6 months
between releases. I like the idea to get new small features regularly
(phobos API enhancement,...), and on some release getting a long wait
hudge feature like Allocators.
Small releases will help to community to live with D. It's important to
make noise regularly around the "product". Users will also xp more
progressively in their development.
There is a lot of development I am waiting for my project, I'll really
be happy to see one come before the next summer :
- std.logger
- std.serialization
- Weak Ptr
- New signals/slots
- RPC (Remote procedure call)
- AST Macro
