If I had my way

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat Dec 10 12:34:05 PST 2011


On 12/10/11 2:14 PM, Andrew Wiley wrote:
> On Sat, Dec 10, 2011 at 2:00 PM, David Nadlinger<see at 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


More information about the Digitalmars-d mailing list