Christopher Wright, el 12 de mayo a las 19:14 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el 12 de mayo a las 09:40 me escribiste:
> >>Tomas Lindquist Olsen wrote:
> >>>Is there a reason for the missing announcement ?
> >>Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.
> >I think a better way to do prereleases is to do a "full" release but mark
> >it as a release candidate.
> >For example, make a DMD 1.045rc release. Wait a week, if nobody complains,
> >release DMD 1.045. If somebody complains, fix the bug, make a DMD
> >1.045rc2, etc (normally the final would be the same as the rc, and there
> >should be very rare cases where a rc2+ would be needed). Maybe it's
> >a little more work, but I'm sure the prerelease will get a lot more
> >testing than a hidden release and people won't get confused thinking that
> >something that is in the website ready for download and looks like a final
> >release, really is a "hidden prerelease".
> >Anyways, I think pre-releasing is great and it's better to have it this
> >way than not having them at all.
> 
> -rc is good when you have long release cycles. It isn't appropriate for dmd, which has very short release cycles.

The Linux kernel has a release every 3 months (aprox.) and they release
about 10 rc for each version.

DMD is released roughly every month. I think having 1 or 2 rc version (just when they are needed, not like the Linux kernel where it's know that there will be more than 5 rc for sure) makes perfect sense.

> If dmd had public source control, we could set up continuous integration for it that will, for instance, run dstress and attempt to compile the latest release of various common libraries. Then Walter can just check its results when he wants to do a release -- depending on how long that takes to run.

This would be very nice indeed, I suggested to put DMD (specially the
frontend) in a SCM a long time ago, but I think this is orthogonal with
the rc. A lot of people don't want to keep checking a development version.
They just want to test the compiler as it would be release (considered
a "finished version") to report weird regressions.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
DESCARTAN BIDET VIRTUAL PORQUE NO LAVA
	-- Cronista TV

Tomas Lindquist Olsen wrote:
> Is there a reason for the missing announcement ?

Well, traditionally (as during the last ten years), Walter has made the announcements of new D releases. It's hardly conceivable that he'd forget to do so, all of a sudden.

If there's no announcement, then there's a reason for it.

(But you're right, updating the changelog when not announcing a new version in this NG, is a deviation from established praxis. So it's understandable that you brought it up, this time.)

((For other readers, a question in the regular D newsgroup would have been more appropriate.))

On Tue, 12 May 2009 23:58:32 -0300, Leandro Lucarella wrote:

> Christopher Wright, el 12 de mayo a las 19:14 me escribiste:
>> Leandro Lucarella wrote:
>> >Walter Bright, el 12 de mayo a las 09:40 me escribiste:
>> >>Tomas Lindquist Olsen wrote:
>> >>>Is there a reason for the missing announcement ?
>> >>Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.
>> >I think a better way to do prereleases is to do a "full" release but
>> >mark it as a release candidate.
>> >For example, make a DMD 1.045rc release. Wait a week, if nobody
>> >complains, release DMD 1.045. If somebody complains, fix the bug, make
>> >a DMD 1.045rc2, etc (normally the final would be the same as the rc,
>> >and there should be very rare cases where a rc2+ would be needed).
>> >Maybe it's a little more work, but I'm sure the prerelease will get a
>> >lot more testing than a hidden release and people won't get confused
>> >thinking that something that is in the website ready for download and
>> >looks like a final release, really is a "hidden prerelease". Anyways,
>> >I think pre-releasing is great and it's better to have it this way
>> >than not having them at all.
>> 
>> -rc is good when you have long release cycles. It isn't appropriate for dmd, which has very short release cycles.
> 
> The Linux kernel has a release every 3 months (aprox.) and they release
> about 10 rc for each version.
> 
> DMD is released roughly every month. I think having 1 or 2 rc version (just when they are needed, not like the Linux kernel where it's know that there will be more than 5 rc for sure) makes perfect sense.
> 
>> If dmd had public source control, we could set up continuous integration for it that will, for instance, run dstress and attempt to compile the latest release of various common libraries. Then Walter can just check its results when he wants to do a release -- depending on how long that takes to run.
> 
> This would be very nice indeed, I suggested to put DMD (specially the frontend) in a SCM a long time ago, but I think this is orthogonal with the rc. A lot of people don't want to keep checking a development version. They just want to test the compiler as it would be release (considered a "finished version") to report weird regressions.

The issue with having rc releases is exactly the same as the one for the stable release which we already have. We don't have the people to coordinate when the release is "good enough." I'm not talking users, but those that are living on the edge and finding flaws.

Maybe what should be done is once Walter releases a version, the library writers that want their code working for the "stable" release should speak approval for increasing the stable version?

On Tue, 12 May 2009 12:40:11 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Tomas Lindquist Olsen wrote:
>> Is there a reason for the missing announcement ?
>
> Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.

This should be a private release then.

If 1.045 is to be a "pre-release", then it should not be on the web site.  If 1.045 has some critical bug that you decide needs to be fixed, then do you release 1.045 again with the fix, or 1.046?  The only sane choice is to not rerelease a version that people already have, that would make bug reporting a constant struggle (oh, you have 1.045?  Is that the broken 1.045 or the good 1.045?) not only for DMD but for other projects where compiler version is important in the bug reports.  A prerelease version of DMD should be marked as such (i.e. 1.045rc as people have suggested).

I'm not trying to cause trouble, I just don't want to see something like this (2 releases with the same identifier).  I know in the past I've advocated for "prerelease" versions, but I meant private pre-release.  The response was always, "how do you know who should get the prerelease?"  It's a fair point.  The counter argument is, libraries like Tango have to blanketly disregard all bugs reported with a broken compiler, which sometimes isn't included on the bug report.

-Steve

Steven Schveighoffer wrote:
> On Tue, 12 May 2009 12:40:11 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
> 
>> Tomas Lindquist Olsen wrote:
>>> Is there a reason for the missing announcement ?
>>
>> Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.
> 
> This should be a private release then.
> 
> If 1.045 is to be a "pre-release", then it should not be on the web site.  If 1.045 has some critical bug that you decide needs to be fixed, then do you release 1.045 again with the fix, or 1.046?  The only sane choice is to not rerelease a version that people already have, that would make bug reporting a constant struggle (oh, you have 1.045?  Is that the broken 1.045 or the good 1.045?) not only for DMD but for other projects where compiler version is important in the bug reports.  A prerelease version of DMD should be marked as such (i.e. 1.045rc as people have suggested).

Agreed. This is why recently DMD2.028 was released, rather than a re-release of DMD2.027 with bug 2812 fixed.

> 
> I'm not trying to cause trouble, I just don't want to see something like this (2 releases with the same identifier).  I know in the past I've advocated for "prerelease" versions, but I meant private pre-release.  

Private prereleases are happening. This was actually DMD2.030 RC3.

> The response was always, "how do you know who should get the prerelease?"  It's a fair point.  The counter argument is, libraries like Tango have to blanketly disregard all bugs reported with a broken compiler, which sometimes isn't included on the bug report.
> 
> -Steve

Tomas Lindquist Olsen wrote:
> Is there a reason for the missing announcement ?
> 
> http://digitalmars.com/d/1.0/changelog.html#new1_045
> 
> http://www.digitalmars.com/d/2.0/changelog.html#new2_030
> 
> and what happened to 1.044 ?
> 
> -Tomas

NOTE:

These releases fix _every_ D2 compiler segfault, stack overflow, or hang which was reported in DStress or Bugzilla prior to today. Two D1-specific bugs were accidentally missed.

Leandro Lucarella wrote:
> Christopher Wright, el 12 de mayo a las 19:14 me escribiste:
>> Leandro Lucarella wrote:
>>> Walter Bright, el 12 de mayo a las 09:40 me escribiste:
>>>> Tomas Lindquist Olsen wrote:
>>>>> Is there a reason for the missing announcement ?
>>>> Yes, I sent it to people who'd asked for a prerelease so they could
>>>> check their builds against it.
>>> I think a better way to do prereleases is to do a "full" release but mark
>>> it as a release candidate.
>>> For example, make a DMD 1.045rc release. Wait a week, if nobody complains,
>>> release DMD 1.045. If somebody complains, fix the bug, make a DMD
>>> 1.045rc2, etc (normally the final would be the same as the rc, and there
>>> should be very rare cases where a rc2+ would be needed). Maybe it's
>>> a little more work, but I'm sure the prerelease will get a lot more
>>> testing than a hidden release and people won't get confused thinking that
>>> something that is in the website ready for download and looks like a final
>>> release, really is a "hidden prerelease".
>>> Anyways, I think pre-releasing is great and it's better to have it this
>>> way than not having them at all.
>> -rc is good when you have long release cycles. It isn't appropriate for
>> dmd, which has very short release cycles.
> 
> The Linux kernel has a release every 3 months (aprox.) and they release
> about 10 rc for each version.
> 
> DMD is released roughly every month. I think having 1 or 2 rc version
> (just when they are needed, not like the Linux kernel where it's know that
> there will be more than 5 rc for sure) makes perfect sense.

Releases take effort. If more people were involved with D -- even in a decoupled sense, which could be provided simply by putting DMD on public source control -- then people other than Walter could manage release candidates.

Don mentioned that there are, in fact, release candidates for dmd. However, private RCs are easier to manage than public ones.

>> If dmd had public source control, we could set up continuous integration
>> for it that will, for instance, run dstress and attempt to compile the
>> latest release of various common libraries. Then Walter can just check
>> its results when he wants to do a release -- depending on how long that
>> takes to run.
> 
> This would be very nice indeed, I suggested to put DMD (specially the
> frontend) in a SCM a long time ago, but I think this is orthogonal with
> the rc. A lot of people don't want to keep checking a development version.
> They just want to test the compiler as it would be release (considered
> a "finished version") to report weird regressions.

Automating as much of that as possible would help.

Christopher Wright wrote:
> If dmd had public source control, we could set up continuous integration for it that will, for instance, run dstress and attempt to compile the latest release of various common libraries. Then Walter can just check its results when he wants to do a release -- depending on how long that takes to run.

This is already done (to an extent) for ldc after each changeset at http://ldc.buildbot.octarineparrot.com/ (note that this needs updating to llvm /trunk, hence all the failures currently).

If Walter is willing to put dmd under public source control I'd happily set this up to automatically compile dmd, run tests suites, compile libraries etc. I could even set up a one command/one click release candidate/final release thing if needed (maybe even nightly builds too).

Robert Clipsham, el 14 de mayo a las 13:11 me escribiste:
> Christopher Wright wrote:
> >If dmd had public source control, we could set up continuous integration for it that will, for instance, run dstress and attempt to compile the latest release of various common libraries. Then Walter can just check its results when he wants to do a release -- depending on how long that takes to run.
> 
> This is already done (to an extent) for ldc after each changeset at
> http://ldc.buildbot.octarineparrot.com/ (note that this needs updating
> to llvm /trunk, hence all the failures currently).

I can't access to this URL right now, it is really working?

> If Walter is willing to put dmd under public source control I'd happily set this up to automatically compile dmd, run tests suites, compile libraries etc. I could even set up a one command/one click release candidate/final release thing if needed (maybe even nightly builds too).

That would be great. What would be the excuse not to do this? =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------

Leandro Lucarella wrote:
> I can't access to this URL right now, it is really working?

Yes, sorry, I picked the perfect time to make a post... I started doing some upgrades to my server about 20 minutes after posting this :P

It is back up now.

> That would be great. What would be the excuse not to do this? =)

Well, only Walter can answer this :)