On Sun, 15 Jul 2012 14:36:06 -0700, SomeDude <[email protected]>
wrote:
On Sunday, 15 July 2012 at 20:50:47 UTC, Patrick Stewart wrote:
OTOH, it may break the community yet again, which we certainly don't
want, probably even less than breaking code.
Also, the example of Python with two main stable branches that live in
parallel is not very encouraging.
Also, check Python website: they recommend python v2 for all new users
that don't know what to choose. They are both stable, but v2 has more
libraries, and they do reassure them by saying v2 will be supported for
time to come.
On the other hand, on D website, D1 is pushed to the dark corners as
ugly half child nobody should know about, and D2 is titled as thing to
chose without thinking. And there is no mentioning D1 is relatively
stable, while D2 is still unstable, non conforming to D documentation
and that some things just don't work, while in constant beta flux that
breaks things on regular basis with each release.
So tell me again, which language treats its users with more respect ?
Which one encourages users more to use them?
The problem I raised is not a problem of respect. It's a problem of
community. The D community is a tiny fraction of the Python community.
It has been steadily growing this last year and a half or so, but it's
still fragile. The D1/D2 split basically set it back to near zero for
several years, with many people leaving, only a few staying, and a
number recently coming back.
The project certainly can't afford yet another split, or many key people
will simply throw the towel. I for one would rather see part of the
users quitting than active members.
As for the stability of D2, upir opinion may be different, but it has
largely improved recently due to increased forces, as several people
have noted (David Simcha in a recent thread said something about the
stability of the compiler being good enough that he only rarely
encountered a problem). And considering the rate of bugs correction, it
will continue to improve. You only need to have a look at the changelog
to see that it's growing with each release, and I'm pretty confident
that the 2.060 will contain more bug fixes than any past release.
You are concerned that adopting an OSS best-practice is going to split the
community ... seriously? I find that a very hard argument to swallow with
a straight face. We aren't splitting D2 into a D3, are simply arguing for
a bugfix branch (stable) and a new feature branch (dev). How, pray tell,
is this a split? We are merely seeking to make two things that are
logically unrelated, bugs and new features, and make them physically
unrelated as well.
The idea that bugs and new features can and should be rolled into the same
release runs counter to every accepted best practice in both FOSS and
Commercial wisdom. The two have VERY different velocities, bugs can be
fixed in days, but new features take much longer. Consider COFF support
for example, Walter has been hammering away at it for weeks now, and he
isn't even 50% done, how many bugs have been fixed and confirmed resolved,
in the same timespan? Also, consider that adding new features makes it
significantly harder to track down regressions (is a real regression or
did the new feature upset the code in an unexpected way) and the new
features themselves create new bugs. If the branches are separate then it
becomes trivial to determine if the new feature caused the bug, because it
will show up in one and not the other.
How DARE we DEMAND that our users wait 4 MONTHS for regression fixes
because we are afraid of a split or a little extra work? How many users
could we lose if we significantly slowed down the release cycle (and
therefore the bugfix cycle) such that people are waiting many months for
their fixes? The language would be perceived as dead/dying and that would
be just as bad as the D1/D2 split. If you allow your past experiences to
paralyze you into inaction, you will bring about the very problem you seek
to avoid.
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
