On 12/10/11 2:14 PM, Andrew Wiley wrote:
On Sat, Dec 10, 2011 at 2:00 PM, David Nadlinger<s...@klickverbot.at> wrote:
I certainly appreciate the general statement, as keeping ones users happy is
one of the most important, if not the single most important thing, to a
positive image.
However, please don't forget that there has already been put quite a lot of
effort into making the current version ready for release (I don't think
there are any blockers left, are there?). Addressing all the points raised
would require several potentially high impact changes, which could easily
set us back for two or three weeks.
Also, the soon-to-be 2.057 fixes quite a few codegen bugs, which are
notoriously troublesome since tracing them down takes a lot of effort.
And personally, I'd like to see a new version being released soon because
I'd otherwise have to tell Thrift people to use a Git version of DMD when I
post my GSoC project for upstream inclusion, which I can't postpone
infinitely. ;)
As 2.057 will contain a few additions which could potentially require some
fixes before they can be considered stable, my proposal would be to release
2.057 now, and aim for a quick 2.058 to address both the issues you
mentioned, and any problems turned up by FReD/OS X x86_64 being used in the
real world.
^^
I agree. Postponing the current release doesn't really do anything but
frustrate the people that depend on recent changes. Setting a goal for
the next release accomplishes the same goals without the added
frustration.
There are good ways of addressing that. We can delay the release by only
a few days and fix long-standing and extremely important issues. This is
not only about doing the expected/reasonable thing here, but breaking a
pattern and making a statement.
We might try making a list of current bugs that *must* be resolved in
the next release. The size of the list would have to be carefully
controlled, but it would bridge the gap between the compiler
developers and the community.
That's a great idea going forward.
Andrei
