www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD release candidates

reply Frank Benoit <keinfarbton googlemail.com> writes:
I would like to see release candidates for DMD releases.

Each new DMD release can have regression bugs. Each new release may fix 
one bug, but other new features (D2.x) or just other bug fixes may 
introduce other regressions.
User with a big code base have therefor a good chance to get a serie of 
releases which are not usable for their software.

So i suggest release candidates.
Release a DMD version as eg. 1.031RC1, then wait some days. If 
regression bugs show up, fix only them and create with that 1.031RC2. 
Only do that with regressions. If then no more regressions show up, 
create the 1.031 release as a copy of the latest release candidate.

This would give developer the best chance to have newest DMD really 
available for their software. And this again makes it possible that 
those users can create bug reports with the newest DMD release.
May 23 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Frank Benoit Wrote:


 I would like to see release candidates for DMD releases.
 
 Each new DMD release can have regression bugs. Each new release may fix 
 one bug, but other new features (D2.x) or just other bug fixes may 
 introduce other regressions.
 User with a big code base have therefor a good chance to get a serie of 
 releases which are not usable for their software.
 
 So i suggest release candidates.
 Release a DMD version as eg. 1.031RC1, then wait some days. If 
 regression bugs show up, fix only them and create with that 1.031RC2. 
 Only do that with regressions. If then no more regressions show up, 
 create the 1.031 release as a copy of the latest release candidate.
 
 This would give developer the best chance to have newest DMD really 
 available for their software. And this again makes it possible that 
 those users can create bug reports with the newest DMD release.
 


Another side benefit - This process could allow a way for library vendors to
sync with a release before it happens.  This could mean that when a release
candidate is finally accepted, the libraries could be bundled with them. 
Personally, I'm thinking of a D 1.x + Tango bundle would be great.
May 23 2008
parent Sebastian Beschke <s.beschke gmx.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason House schrieb:
| Another side benefit - This process could allow a way for library
vendors to sync with a release before it happens.  This could mean that
when a release candidate is finally accepted, the libraries could be
bundled with them.  Personally, I'm thinking of a D 1.x + Tango bundle
would be great.

There's already a DMD+Tango bundle:
http://www.dsource.org/projects/tango/wiki/DmdDownloads

There's also DMD Snapshot.
http://www.fsdev.net/gf/project/dmd-snaps/frs/?action=FrsReleaseView&release_id=109

I personally think the release process for DMD itself should stay as
simple as possible; "outsourcing" the release process like the mentioned
DMD Snapshot is a better solution IMHO.

Regards
Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIN0QtKb/1n5A2TAMRAobPAJ47Yl1K64LN9kSdKiipd6MppJREIwCfdus3
ifA/NMVleML7k21w6WO7owE=
=29gI
-----END PGP SIGNATURE-----
May 23 2008