"Adam Wilson" <flyboynw gmail.com> writes:

As a result of the D Versioning thread, we have decided to create a new  
organization on Github called dlang-stable. This organization will be  
responsible for maintaining stable releases of DMD, DRuntime, and Phobos.

So what is a stable release?
A stable release is a complete build of DMD, DRuntime, and Phobos that  
ONLY includes the latest bug-fixes and non-breaking enhancements to  
existing features. It will not include, new features, breaking  
enhancements, and any other code that the core development team may be  
working on.

How often will you release?
The goal of this project is that D is stable at all times. Therefore, our  
primary method of release will simply be Git-HEAD. However, we will also  
make available frequent packaged distributions for those who may be unable  
to use Git-HEAD. While the exact release cadence is to be determined, we  
expect it to be more frequent then the current release schedule.

What if a bug fix breaks my code?
We will still issue the fix. Fixing the broken behavior is more important  
than allowing broken code to continue.

How much will the core team be involved?
The idea behind this project is that the core team needs to focus on  
developing D as fast as possible. However, we will coordinate with them as  
necessary when it is time to pull in the latest work from the development  
repositories and as any conflicts arise to between the two codebases.

Is this a fork of D?
No. Our goal is to follow the development of D perfectly. All the code for  
the stable releases will be received from the primary repositories. We  
will simply be cherry-picking the commits we want in the release.

Will new features ever be merged from the primary repositories?
Yes. As new features mature, they will be pulled into the stable repos.  
Precisely when this happens will be a mutual decision by all the  
developers involved and the community at large.

I have a bug fix ready to go. Who do I send the pull request to?
Please send all pull requests to the primary development repositories  
(D-Programming-Language). From there we will incorporate your fixes as  
they are merged into the primary repositories.

I still want to hack on DMD/DRuntme/Phobos. Where do I point my local  
repositories?
Then nothing will change for you. You can keep all your existing remotes.

Who is developing this project?
For the moment, just myself, with support from Andrei. Although, it would  
be much appreciated if a few others would step forward as release  
maintainers to help with the bug fix merges and quality control. If you  
are interested, I would love to hear from you. You can reply here, send me  
an email, or contact me on GitHub (handle: LightBender).

OK, I'm sold! When will the first Stable release be ready?
Not until after the official release of 2.060. We feel that it is best to  
this project from a released build of DMD and from then on maintain the  
stable versions. While it is technically feasible to go back and start  
 from 2.059, the number of bug fixes since then it would make it a  
gargantuan task. In addition, this period allows us to build-up the  
release team, synchronize with the core team, and polish our release  
procedures. After 2.060 we will begin releasing stable versions of D

Where can I find these stable releases?
The stable releases are located on GitHub at  
https://github.com/dlang-stable
Once the packaged release become available you can expect to see them on  
http://www.dlang.org/

If you have any more questions or comments, please reply below and will  
attempt to answer them to the best of my ability.

Thank you for reading and I hope you enjoy D's new Stable releases!

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Jacob Carlborg <doob me.com> writes:

On 2012-07-16 09:51, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a new
 organization on Github called dlang-stable. This organization will be
 responsible for maintaining stable releases of DMD, DRuntime, and Phobos.

 So what is a stable release?
 A stable release is a complete build of DMD, DRuntime, and Phobos that
 ONLY includes the latest bug-fixes and non-breaking enhancements to
 existing features. It will not include, new features, breaking
 enhancements, and any other code that the core development team may be
 working on.

 How often will you release?
 The goal of this project is that D is stable at all times. Therefore,
 our primary method of release will simply be Git-HEAD. However, we will
 also make available frequent packaged distributions for those who may be
 unable to use Git-HEAD. While the exact release cadence is to be
 determined, we expect it to be more frequent then the current release
 schedule.

 What if a bug fix breaks my code?
 We will still issue the fix. Fixing the broken behavior is more
 important than allowing broken code to continue.

 How much will the core team be involved?
 The idea behind this project is that the core team needs to focus on
 developing D as fast as possible. However, we will coordinate with them
 as necessary when it is time to pull in the latest work from the
 development repositories and as any conflicts arise to between the two
 codebases.

 Is this a fork of D?
 No. Our goal is to follow the development of D perfectly. All the code
 for the stable releases will be received from the primary repositories.
 We will simply be cherry-picking the commits we want in the release.

 Will new features ever be merged from the primary repositories?
 Yes. As new features mature, they will be pulled into the stable repos.
 Precisely when this happens will be a mutual decision by all the
 developers involved and the community at large.

 I have a bug fix ready to go. Who do I send the pull request to?
 Please send all pull requests to the primary development repositories
 (D-Programming-Language). From there we will incorporate your fixes as
 they are merged into the primary repositories.

 I still want to hack on DMD/DRuntme/Phobos. Where do I point my local
 repositories?
 Then nothing will change for you. You can keep all your existing remotes.

 Who is developing this project?
 For the moment, just myself, with support from Andrei. Although, it
 would be much appreciated if a few others would step forward as release
 maintainers to help with the bug fix merges and quality control. If you
 are interested, I would love to hear from you. You can reply here, send
 me an email, or contact me on GitHub (handle: LightBender).

 OK, I'm sold! When will the first Stable release be ready?
 Not until after the official release of 2.060. We feel that it is best
 to this project from a released build of DMD and from then on maintain
 the stable versions. While it is technically feasible to go back and
 start from 2.059, the number of bug fixes since then it would make it a
 gargantuan task. In addition, this period allows us to build-up the
 release team, synchronize with the core team, and polish our release
 procedures. After 2.060 we will begin releasing stable versions of D

 Where can I find these stable releases?
 The stable releases are located on GitHub at
 https://github.com/dlang-stable
 Once the packaged release become available you can expect to see them on
 http://www.dlang.org/

 If you have any more questions or comments, please reply below and will
 attempt to answer them to the best of my ability.

 Thank you for reading and I hope you enjoy D's new Stable releases!

Thanks for properly announcing this.

Question: are the going to be release only from "dlang-stable" or from 
the current repositories as well.

-- 
/Jacob Carlborg

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 01:14:40 -0700, Jacob Carlborg <doob me.com> wrote:

 On 2012-07-16 09:51, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a new
 organization on Github called dlang-stable. This organization will be
 responsible for maintaining stable releases of DMD, DRuntime, and  
 Phobos.

 So what is a stable release?
 A stable release is a complete build of DMD, DRuntime, and Phobos that
 ONLY includes the latest bug-fixes and non-breaking enhancements to
 existing features. It will not include, new features, breaking
 enhancements, and any other code that the core development team may be
 working on.

 How often will you release?
 The goal of this project is that D is stable at all times. Therefore,
 our primary method of release will simply be Git-HEAD. However, we will
 also make available frequent packaged distributions for those who may be
 unable to use Git-HEAD. While the exact release cadence is to be
 determined, we expect it to be more frequent then the current release
 schedule.

 What if a bug fix breaks my code?
 We will still issue the fix. Fixing the broken behavior is more
 important than allowing broken code to continue.

 How much will the core team be involved?
 The idea behind this project is that the core team needs to focus on
 developing D as fast as possible. However, we will coordinate with them
 as necessary when it is time to pull in the latest work from the
 development repositories and as any conflicts arise to between the two
 codebases.

 Is this a fork of D?
 No. Our goal is to follow the development of D perfectly. All the code
 for the stable releases will be received from the primary repositories.
 We will simply be cherry-picking the commits we want in the release.

 Will new features ever be merged from the primary repositories?
 Yes. As new features mature, they will be pulled into the stable repos.
 Precisely when this happens will be a mutual decision by all the
 developers involved and the community at large.

 I have a bug fix ready to go. Who do I send the pull request to?
 Please send all pull requests to the primary development repositories
 (D-Programming-Language). From there we will incorporate your fixes as
 they are merged into the primary repositories.

 I still want to hack on DMD/DRuntme/Phobos. Where do I point my local
 repositories?
 Then nothing will change for you. You can keep all your existing  
 remotes.

 Who is developing this project?
 For the moment, just myself, with support from Andrei. Although, it
 would be much appreciated if a few others would step forward as release
 maintainers to help with the bug fix merges and quality control. If you
 are interested, I would love to hear from you. You can reply here, send
 me an email, or contact me on GitHub (handle: LightBender).

 OK, I'm sold! When will the first Stable release be ready?
 Not until after the official release of 2.060. We feel that it is best
 to this project from a released build of DMD and from then on maintain
 the stable versions. While it is technically feasible to go back and
 start from 2.059, the number of bug fixes since then it would make it a
 gargantuan task. In addition, this period allows us to build-up the
 release team, synchronize with the core team, and polish our release
 procedures. After 2.060 we will begin releasing stable versions of D

 Where can I find these stable releases?
 The stable releases are located on GitHub at
 https://github.com/dlang-stable
 Once the packaged release become available you can expect to see them on
 http://www.dlang.org/

 If you have any more questions or comments, please reply below and will
 attempt to answer them to the best of my ability.

 Thank you for reading and I hope you enjoy D's new Stable releases!

 Thanks for properly announcing this.

 Question: are the going to be release only from "dlang-stable" or from  
 the current repositories as well.

For the moment both. This is just an experimental project. And most  
projects with stable and development branches release from both. I see no  
reason not to continue releasing from DEV as well as STABLE. Pick your  
poison. :)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

"Roman D. Boiko" <rb d-coding.com> writes:

On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to 
 create a new organization on Github called dlang-stable. This 
 organization will be responsible for maintaining stable 
 releases of DMD, DRuntime, and Phobos.

Congratulations!

I also proposed this idea:

 Also, nobody is preventing any person that considers this to be 
 very important from creating a fork of stable branch and 
 applying bug-fixes there. If this happens to be a very useful 
 option, then it could be accepted as a policy.

 So my point of view is that it might be too early to have such 
 policy yet.

http://forum.dlang.org/post/ovtazudocniqfcwzxpky forum.dlang.org

Also I propose to have a download page with tracking statistics. 
This would be a nice feedback tool for multiple purposes.

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 01:29:35 -0700, Roman D. Boiko <rb d-coding.com> wrote:

 On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a new  
 organization on Github called dlang-stable. This organization will be  
 responsible for maintaining stable releases of DMD, DRuntime, and  
 Phobos.

 Congratulations!

 I also proposed this idea:

 Also, nobody is preventing any person that considers this to be very  
 important from creating a fork of stable branch and applying bug-fixes  
 there. If this happens to be a very useful option, then it could be  
 accepted as a policy.

 So my point of view is that it might be too early to have such policy  
 yet.

 http://forum.dlang.org/post/ovtazudocniqfcwzxpky forum.dlang.org

That is effectively what we have done here. The dlang-stable repos are  
forks of the current repos and rely on them for their bug-fix commits.  
While not everyone agrees that this is the right path, it's the best  
compromise we could come up with ... and everybody is unhappy, I'd call  
that a success! ;-)

 Also I propose to have a download page with tracking statistics. This  
 would be a nice feedback tool for multiple purposes.

Andrei has said that he would be willing to provide this support on the  
website and Walter approves.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Leandro Lucarella <luca llucax.com.ar> writes:

Adam Wilson, el 16 de July a las 00:51 me escribiste:
 As a result of the D Versioning thread, we have decided to create a
 new organization on Github called dlang-stable. This organization
 will be responsible for maintaining stable releases of DMD,
 DRuntime, and Phobos.

What will be the version scheme of this dlang-stable compiler? If the
git master branch will be the "release", will you increase that version
number on each and every commit?

I think it would be a good idea to make real releases, with rc and
everything to minimize the chances of introducing (untested)
regressions (bare in mind that a lot of patches will not merge cleanly
so knowing that the original patch introduced no regressions in the
devel compiler doesn't mean it will be the same when merged in the
stable one).

That said, I think it was about time D separate devel from stable, so
thanks for stepping forward :)

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Soy como una mosca, parada en el agua.
Y vos sos un transatlántico, querés nadar a mi lado.
Y me estás ahogando.

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 01:56:23 -0700, Leandro Lucarella <luca llucax.com.a=
r>  =

wrote:

 Adam Wilson, el 16 de July a las 00:51 me escribiste:
 As a result of the D Versioning thread, we have decided to create a
 new organization on Github called dlang-stable. This organization
 will be responsible for maintaining stable releases of DMD,
 DRuntime, and Phobos.

 What will be the version scheme of this dlang-stable compiler? If the
 git master branch will be the "release", will you increase that versio=

n
 number on each and every commit?

We will probably only bump the version number for packaged releases.  =

Anything else is going to be a lot of relatively useless wheel-spinning.=


 I think it would be a good idea to make real releases, with rc and
 everything to minimize the chances of introducing (untested)
 regressions (bare in mind that a lot of patches will not merge cleanly=

 so knowing that the original patch introduced no regressions in the
 devel compiler doesn't mean it will be the same when merged in the
 stable one).

One option to help alleviate this concern is to do the initial cherry-pi=
ck  =

on a separate branch and merge it in once it passes the unittests. This =
is  =

a benefit of using a separate GitHub organization.

 That said, I think it was about time D separate devel from stable, so
 thanks for stepping forward :)

You're welcome!

 --
 Leandro Lucarella (AKA luca)                     http://llucax.com.ar/=

 ----------------------------------------------------------------------=

 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)=

 ----------------------------------------------------------------------=

 Soy como una mosca, parada en el agua.
 Y vos sos un transatl=E1ntico, quer=E9s nadar a mi lado.
 Y me est=E1s ahogando.


-- =

Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Leandro Lucarella <luca llucax.com.ar> writes:

Adam Wilson, el 16 de July a las 11:01 me escribiste:
 On Mon, 16 Jul 2012 01:56:23 -0700, Leandro Lucarella
 <luca llucax.com.ar> wrote:

Adam Wilson, el 16 de July a las 00:51 me escribiste:
As a result of the D Versioning thread, we have decided to create a
new organization on Github called dlang-stable. This organization
will be responsible for maintaining stable releases of DMD,
DRuntime, and Phobos.

What will be the version scheme of this dlang-stable compiler? If the
git master branch will be the "release", will you increase that version
number on each and every commit?

 We will probably only bump the version number for packaged releases.
 Anything else is going to be a lot of relatively useless
 wheel-spinning.

What I would suggest is if you fork from 1.060, to release 1.060.1,
1.060.2, etc. So is easy to find out what set of features are present in
a stable release every time.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Robar un alfajor es revolucionario, pues rompe con la idea de propiedad,
incluso más que si se tratara de dinero.
	-- publikazion anarkista mdp (hablando de los destrozos de la
	   Cumbre de las Americas en Mar del Plata, 2005)

"Adam Wilson" <flyboynw gmail.com> writes:

On Sat, 21 Jul 2012 07:27:39 -0700, Leandro Lucarella <luca llucax.com.a=
r>  =

wrote:

 Adam Wilson, el 16 de July a las 11:01 me escribiste:
 On Mon, 16 Jul 2012 01:56:23 -0700, Leandro Lucarella
 <luca llucax.com.ar> wrote:

Adam Wilson, el 16 de July a las 00:51 me escribiste:
As a result of the D Versioning thread, we have decided to create a=




new organization on Github called dlang-stable. This organization
will be responsible for maintaining stable releases of DMD,
DRuntime, and Phobos.

What will be the version scheme of this dlang-stable compiler? If th=



e
git master branch will be the "release", will you increase that vers=



ion
number on each and every commit?

 We will probably only bump the version number for packaged releases.
 Anything else is going to be a lot of relatively useless
 wheel-spinning.

 What I would suggest is if you fork from 1.060, to release 1.060.1,
 1.060.2, etc. So is easy to find out what set of features are present =

in
 a stable release every time.

This seems to be the general consensus and I think it's where we'll go.

 --
 Leandro Lucarella (AKA luca)                     http://llucax.com.ar/=

 ----------------------------------------------------------------------=

 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)=

 ----------------------------------------------------------------------=

 Robar un alfajor es revolucionario, pues rompe con la idea de propieda=

d,
 incluso m=E1s que si se tratara de dinero.
 	-- publikazion anarkista mdp (hablando de los destrozos de la
 	   Cumbre de las Americas en Mar del Plata, 2005)


-- =

Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

"David Nadlinger" <see klickverbot.at> writes:

On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to 
 create a new organization on Github called dlang-stable. This 
 organization will be responsible for maintaining stable 
 releases of DMD, DRuntime, and Phobos.

For the time being, I'd rather be explicit about who we is, and 
that this is not an »official« (whatever this really means) 
endeavor yet. Don't get me wrong, the idea is indeed nice, and 
probably it will work out just well. I only doubt that it is a 
good idea to raise expectations too high at this point…

David

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 02:59:31 -0700, David Nadlinger <see klickverbot.at>=
  =

wrote:

 On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a n=


ew  =

 organization on Github called dlang-stable. This organization will be=


  =

 responsible for maintaining stable releases of DMD, DRuntime, and  =


 Phobos.

 For the time being, I'd rather be explicit about who we is, and that  =

 this is not an =C2=BBofficial=C2=AB (whatever this really means) endea=

vor yet.  =

 Don't get me wrong, the idea is indeed nice, and probably it will work=

  =

 out just well. I only doubt that it is a good idea to raise expectatio=

ns  =

 too high at this point=E2=80=A6

 David

It's not official, yet. But it does have the backing of the Walter and  =

Andrei. So if this experiment is successful then it will likely be made =
 =

official. And you guys can help make it successful by supporting it. And=
  =

it needs all the help it can get! I am just one guy who has to work for =
a  =

living. :-)

-- =

Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Marco Leise <Marco.Leise gmx.de> writes:

Am Mon, 16 Jul 2012 00:51:16 -0700
schrieb "Adam Wilson" <flyboynw gmail.com>:

For the 2.059 release I waited a while until apparent regressions and oddities
in Phobos (deprecation warnings) were fixed in the main repository before
updating the dmd package for Gentoo. This was quite a bit of manual work
collecting, applying and testing patches from GitHub and the bug tracker.
Will this project be an option for me as a package maintainer? What I need is
basically the official dmd zip file (sources, html docs, man pages, bash
completion, rdmd binary & co.), but with hotfixes applied at about a week or
two after release.
It seems like your work could make this possible and also allow me to issue a
new revision of the package in case of, say a security fix that comes a month
after release.
Last not least, will we get notified about critical/important fixes in the
"stable" branch? 'Cause polling is so old-school ;). RSS, news group, email,
phone call, anything will do. It looks like GitHub has a commit-RSS-feed, but
it would be very noisy on most repositories with messages like "forgot this in
last check-in" or "deleted unused file/code", and not every commit warrants a
new package.

As it shows, the beta phase doesn't always catch all regressions in people's
code, so I encourage you to do this project and eventually it will be used by
GDC and other major from-source projects. By the way: Should this also later
become the base for the official zip file download? IIRC Walter wanted to keep
track of the DMD downloads from the main web site (no redistribution) and
hotfixed versions of D could become increasingly popular.

-- 
Marco

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 16 July 2012 14:00, Marco Leise <Marco.Leise gmx.de> wrote:
 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 As it shows, the beta phase doesn't always catch all regressions in peopl=

e's code, so I encourage you to do this project and eventually it will be u=
sed by GDC and other major from-source projects. By the way: Should this al=
so later become the base for the official zip file download? IIRC Walter wa=
nted to keep track of the DMD downloads from the main web site (no redistri=
bution) and hotfixed versions of D could become increasingly popular.
 --
 Marco

And what benefits would GDC get from opting to use this rather than
the normal releases?


--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';

Marco Leise <Marco.Leise gmx.de> writes:

Am Mon, 16 Jul 2012 17:21:39 +0100
schrieb Iain Buclaw <ibuclaw ubuntu.com>:

 On 16 July 2012 14:00, Marco Leise <Marco.Leise gmx.de> wrote:
 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 As it shows, the beta phase doesn't always catch all regressions in people's
code, so I encourage you to do this project and eventually it will be used by
GDC and other major from-source projects. By the way: Should this also later
become the base for the official zip file download? IIRC Walter wanted to keep
track of the DMD downloads from the main web site (no redistribution) and
hotfixed versions of D could become increasingly popular.

 --
 Marco

 
 And what benefits would GDC get from opting to use this rather than
 the normal releases?

What he said, [regression] fixes that didn't make it into the initial release.
I don't know about GDC's 'patch level', but for 2.059 I applied patches for the
following issues after release, to have it feel as solid as good old 2.058:
- issue-7907
- issue-7911
- issue-7922
- outOfMemoryError-undeprecation
- std-path-sep-deprecation

In case crypto algorithms become part of Phobos, some patches may improve
security as well. Didn't you say you work only with the GitHub release tags for
stability?

-- 
Marco

"Iain Buclaw" <ibuclaw ubuntu.com> writes:

On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote:
 Am Mon, 16 Jul 2012 17:21:39 +0100
 schrieb Iain Buclaw <ibuclaw ubuntu.com>:

 On 16 July 2012 14:00, Marco Leise <Marco.Leise gmx.de> wrote:
 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 As it shows, the beta phase doesn't always catch all 
 regressions in people's code, so I encourage you to do this 
 project and eventually it will be used by GDC and other 
 major from-source projects. By the way: Should this also 
 later become the base for the official zip file download? 
 IIRC Walter wanted to keep track of the DMD downloads from 
 the main web site (no redistribution) and hotfixed versions 
 of D could become increasingly popular.

 --
 Marco

 
 And what benefits would GDC get from opting to use this rather 
 than
 the normal releases?

 What he said, [regression] fixes that didn't make it into the 
 initial release. I don't know about GDC's 'patch level', but 
 for 2.059 I applied patches for the following issues after 
 release, to have it feel as solid as good old 2.058:
 - issue-7907
 - issue-7911
 - issue-7922
 - outOfMemoryError-undeprecation
 - std-path-sep-deprecation

 In case crypto algorithms become part of Phobos, some patches 
 may improve security as well. Didn't you say you work only with 
 the GitHub release tags for stability?

So if I were to represent a theoretical merge sequence in ascii:

            ... former releases ...
    DMD Development             GDC Development
         >---- DMD 2.060 release ---->
         |                           |
     DMD Development         DMD 2.060.1 release
         v                           v
         |                           |
         |                   DMD 2.060.2 release
         |                           v
         |                           |
         |                   DMD 2.060.3 release
         |                           v
         |                           |
     DMD 2.061 beta          DMD 2.060.4 release
         v                           v
         |                           |
     DMD 2.061 RC            DMD 2.060.5 release
         v                           v
         |                           |
         >-- DMD 2.061 release ------>


Would this be a correct way of utilising this new process?



I use Github release tags so I get the correct test suite for the
release I'm merging in.  Other than that the only other special
information you need to know is that I use meld to sync the
frontend and library sources together.


Regards
Iain

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 10:26:31 -0700, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote:
 Am Mon, 16 Jul 2012 17:21:39 +0100
 schrieb Iain Buclaw <ibuclaw ubuntu.com>:

 On 16 July 2012 14:00, Marco Leise <Marco.Leise gmx.de> wrote:
 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 As it shows, the beta phase doesn't always catch all > regressions  

 in people's code, so I encourage you to do this > project and  
 eventually it will be used by GDC and other > major from-source  
 projects. By the way: Should this also > later become the base for the  
 official zip file download? > IIRC Walter wanted to keep track of the  
 DMD downloads from > the main web site (no redistribution) and  
 hotfixed versions > of D could become increasingly popular.
 --
 Marco

  And what benefits would GDC get from opting to use this rather than
 the normal releases?

 What he said, [regression] fixes that didn't make it into the initial  
 release. I don't know about GDC's 'patch level', but for 2.059 I  
 applied patches for the following issues after release, to have it feel  
 as solid as good old 2.058:
 - issue-7907
 - issue-7911
 - issue-7922
 - outOfMemoryError-undeprecation
 - std-path-sep-deprecation

 In case crypto algorithms become part of Phobos, some patches may  
 improve security as well. Didn't you say you work only with the GitHub  
 release tags for stability?

 So if I were to represent a theoretical merge sequence in ascii:

             ... former releases ...
     DMD Development             GDC Development
          >---- DMD 2.060 release ---->
          |                           |
      DMD Development         DMD 2.060.1 release
          v                           v
          |                           |
          |                   DMD 2.060.2 release
          |                           v
          |                           |
          |                   DMD 2.060.3 release
          |                           v
          |                           |
      DMD 2.061 beta          DMD 2.060.4 release
          v                           v
          |                           |
      DMD 2.061 RC            DMD 2.060.5 release
          v                           v
          |                           |
          >-- DMD 2.061 release ------>


 Would this be a correct way of utilising this new process?

I'd say mostly correct. The last step is the one where we might differ  
though, as we may choose to wait on regression and other bug-fixes to any  
new features in that release. But we might not wait if the build consists  
of no new features, just breaking changes to existing ones. It will be  
more of a conversation with the community about how stable they feel the  
changes in the latest release are. For example, of the new COFF support is  
still highly unstable (lots of fix commits), we might wait until that  
settles down before merging in the entirety of the development repos.

So maybe something like:

              ... former releases ...
      DMD Development             GDC Development
           >---- DMD 2.060 release ---->
           |                           |
       DMD Development         DMD 2.060.1 release
           v                           v
           |                           |
           |                   DMD 2.060.2 release
           |                           v
           |                           |
           |                   DMD 2.060.3 release
           |                           v
           |                           |
      DMD 2.061 beta           DMD 2.060.4 release
           v                           v
           |                           |
       DMD 2.061 RC            DMD 2.060.5 release
           v                           v
           |                           |
     DMD 2.061 release         DMD 2.060.6 release
           v                           v
           |                           |
           >----- DMD 2.061 merge ----->

However, the precise versioning scheme is something of an open question,  
and as we gain more experience with this new development model we may  
modify this. Any feedback on this is quite welcome. All this is going to  
require some coordination with the core team.

 I use Github release tags so I get the correct test suite for the
 release I'm merging in.  Other than that the only other special
 information you need to know is that I use meld to sync the
 frontend and library sources together.


 Regards
 Iain


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 16 July 2012 18:56, Adam Wilson <flyboynw gmail.com> wrote:
 On Mon, 16 Jul 2012 10:26:31 -0700, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote:
 Am Mon, 16 Jul 2012 17:21:39 +0100
 schrieb Iain Buclaw <ibuclaw ubuntu.com>:

 On 16 July 2012 14:00, Marco Leise <Marco.Leise gmx.de> wrote:
 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 As it shows, the beta phase doesn't always catch all > regressions in
 people's code, so I encourage you to do this > project and eventually it
 will be used by GDC and other > major from-source projects. By the way:
 Should this also > later become the base for the official zip file download?
 IIRC Walter wanted to keep track of the DMD downloads from > the main web

 site (no redistribution) and hotfixed versions > of D could become
 increasingly popular.

 --
 Marco

  And what benefits would GDC get from opting to use this rather than
 the normal releases?


 What he said, [regression] fixes that didn't make it into the initial
 release. I don't know about GDC's 'patch level', but for 2.059 I applied
 patches for the following issues after release, to have it feel as solid as
 good old 2.058:
 - issue-7907
 - issue-7911
 - issue-7922
 - outOfMemoryError-undeprecation
 - std-path-sep-deprecation

 In case crypto algorithms become part of Phobos, some patches may improve
 security as well. Didn't you say you work only with the GitHub release tags
 for stability?


 So if I were to represent a theoretical merge sequence in ascii:

             ... former releases ...
     DMD Development             GDC Development
          >---- DMD 2.060 release ---->
          |                           |
      DMD Development         DMD 2.060.1 release
          v                           v
          |                           |
          |                   DMD 2.060.2 release
          |                           v
          |                           |
          |                   DMD 2.060.3 release
          |                           v
          |                           |
      DMD 2.061 beta          DMD 2.060.4 release
          v                           v
          |                           |
      DMD 2.061 RC            DMD 2.060.5 release
          v                           v
          |                           |
          >-- DMD 2.061 release ------>


 Would this be a correct way of utilising this new process?

 I'd say mostly correct. The last step is the one where we might differ
 though, as we may choose to wait on regression and other bug-fixes to any
 new features in that release. But we might not wait if the build consists of
 no new features, just breaking changes to existing ones. It will be more of
 a conversation with the community about how stable they feel the changes in
 the latest release are. For example, of the new COFF support is still highly
 unstable (lots of fix commits), we might wait until that settles down before
 merging in the entirety of the development repos.

And how does DMD backend support for COFF affect GDC? :-)



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 11:12:38 -0700, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 16 July 2012 18:56, Adam Wilson <flyboynw gmail.com> wrote:
 On Mon, 16 Jul 2012 10:26:31 -0700, Iain Buclaw <ibuclaw ubuntu.com>  
 wrote:

 On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote:
 Am Mon, 16 Jul 2012 17:21:39 +0100
 schrieb Iain Buclaw <ibuclaw ubuntu.com>:

 On 16 July 2012 14:00, Marco Leise <Marco.Leise gmx.de> wrote:
 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 As it shows, the beta phase doesn't always catch all > regressions  

 in
 people's code, so I encourage you to do this > project and  

 eventually it
 will be used by GDC and other > major from-source projects. By the  

 way:
 Should this also > later become the base for the official zip file  

 download?
 IIRC Walter wanted to keep track of the DMD downloads from > the  


 main web
 site (no redistribution) and hotfixed versions > of D could become
 increasingly popular.

 --
 Marco

  And what benefits would GDC get from opting to use this rather than
 the normal releases?


 What he said, [regression] fixes that didn't make it into the initial
 release. I don't know about GDC's 'patch level', but for 2.059 I  
 applied
 patches for the following issues after release, to have it feel as  
 solid as
 good old 2.058:
 - issue-7907
 - issue-7911
 - issue-7922
 - outOfMemoryError-undeprecation
 - std-path-sep-deprecation

 In case crypto algorithms become part of Phobos, some patches may  
 improve
 security as well. Didn't you say you work only with the GitHub  
 release tags
 for stability?


 So if I were to represent a theoretical merge sequence in ascii:

             ... former releases ...
     DMD Development             GDC Development
          >---- DMD 2.060 release ---->
          |                           |
      DMD Development         DMD 2.060.1 release
          v                           v
          |                           |
          |                   DMD 2.060.2 release
          |                           v
          |                           |
          |                   DMD 2.060.3 release
          |                           v
          |                           |
      DMD 2.061 beta          DMD 2.060.4 release
          v                           v
          |                           |
      DMD 2.061 RC            DMD 2.060.5 release
          v                           v
          |                           |
          >-- DMD 2.061 release ------>


 Would this be a correct way of utilising this new process?

 I'd say mostly correct. The last step is the one where we might differ
 though, as we may choose to wait on regression and other bug-fixes to  
 any
 new features in that release. But we might not wait if the build  
 consists of
 no new features, just breaking changes to existing ones. It will be  
 more of
 a conversation with the community about how stable they feel the  
 changes in
 the latest release are. For example, of the new COFF support is still  
 highly
 unstable (lots of fix commits), we might wait until that settles down  
 before
 merging in the entirety of the development repos.

 And how does DMD backend support for COFF affect GDC? :-)

Very little I imagine. But we are working against DMD. Since you only want  
the front-end fixes, I imagine that (at least in terms of the backend) you  
won't care much when we merge that feature. My point was more general to  
versioning, in that we might update the stable branches to the new release  
day one. The new fixes will still appear though. Obviously this would have  
more impact for you with any new front-end features.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Leandro Lucarella <luca llucax.com.ar> writes:

Adam Wilson, el 16 de July a las 10:56 me escribiste:
So if I were to represent a theoretical merge sequence in ascii:

            ... former releases ...
    DMD Development             GDC Development
         >---- DMD 2.060 release ---->
         |                           |
     DMD Development         DMD 2.060.1 release
         v                           v
         |                           |
         |                   DMD 2.060.2 release
         |                           v
         |                           |
         |                   DMD 2.060.3 release
         |                           v
         |                           |
     DMD 2.061 beta          DMD 2.060.4 release
         v                           v
         |                           |
     DMD 2.061 RC            DMD 2.060.5 release
         v                           v
         |                           |
         >-- DMD 2.061 release ------>


Would this be a correct way of utilising this new process?

 I'd say mostly correct. The last step is the one where we might

Mmm, this makes me wonder if the stable releases based on a particular
official release will live only until the next official release is out,
or if they will be long-term. I thought it was the later, so people
don't have to worry about bugs related to new features they don't care
about, but now I'm not so sure.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
ACCIDENTE FATAL EN FLORES, MUEREN DOS PERSONAS Y UN BOLIVIANO
	-- Crónica TV

"Adam Wilson" <flyboynw gmail.com> writes:

On Sat, 21 Jul 2012 07:32:19 -0700, Leandro Lucarella <luca llucax.com.a=
r>  =

wrote:

 Adam Wilson, el 16 de July a las 10:56 me escribiste:
So if I were to represent a theoretical merge sequence in ascii:

            ... former releases ...
    DMD Development             GDC Development
         >---- DMD 2.060 release ---->
         |                           |
     DMD Development         DMD 2.060.1 release
         v                           v
         |                           |
         |                   DMD 2.060.2 release
         |                           v
         |                           |
         |                   DMD 2.060.3 release
         |                           v
         |                           |
     DMD 2.061 beta          DMD 2.060.4 release
         v                           v
         |                           |
     DMD 2.061 RC            DMD 2.060.5 release
         v                           v
         |                           |
         >-- DMD 2.061 release ------>


Would this be a correct way of utilising this new process?

 I'd say mostly correct. The last step is the one where we might

 Mmm, this makes me wonder if the stable releases based on a particular=

 official release will live only until the next official release is out=

,
 or if they will be long-term. I thought it was the later, so people
 don't have to worry about bugs related to new features they don't care=

 about, but now I'm not so sure.

Actually, I specifically mention that new features will left out until  =

stability is achieved. But at some point we will fold in the new feature=
s  =

 from HEAD, our goal is to specifically AVOID creating a D1/D2 style spl=
it.

 --
 Leandro Lucarella (AKA luca)                     http://llucax.com.ar/=

 ----------------------------------------------------------------------=

 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)=

 ----------------------------------------------------------------------=

 ACCIDENTE FATAL EN FLORES, MUEREN DOS PERSONAS Y UN BOLIVIANO
 	-- Cr=F3nica TV


-- =

Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Leandro Lucarella <luca llucax.com.ar> writes:

Adam Wilson, el 21 de July a las 15:03 me escribiste:
Mmm, this makes me wonder if the stable releases based on a particular
official release will live only until the next official release is out,
or if they will be long-term. I thought it was the later, so people
don't have to worry about bugs related to new features they don't care
about, but now I'm not so sure.

 Actually, I specifically mention that new features will left out
 until stability is achieved. But at some point we will fold in the
 new features from HEAD, our goal is to specifically AVOID creating a
 D1/D2 style split.

Yes, of course, but these updates will not be done for each and every
official DMD release, they will be done in a timespan in the order of
years for example? I.e. like any other serious language out there? :P

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
The biggest lie you can tell yourself is
When I get what I want I will be happy

"Adam Wilson" <flyboynw gmail.com> writes:

On Sun, 22 Jul 2012 11:59:39 -0700, Leandro Lucarella <luca llucax.com.ar>  
wrote:

 Adam Wilson, el 21 de July a las 15:03 me escribiste:
Mmm, this makes me wonder if the stable releases based on a particular
official release will live only until the next official release is out,
or if they will be long-term. I thought it was the later, so people
don't have to worry about bugs related to new features they don't care
about, but now I'm not so sure.

 Actually, I specifically mention that new features will left out
 until stability is achieved. But at some point we will fold in the
 new features from HEAD, our goal is to specifically AVOID creating a
 D1/D2 style split.

 Yes, of course, but these updates will not be done for each and every
 official DMD release, they will be done in a timespan in the order of
 years for example? I.e. like any other serious language out there? :P

 --
 Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
 ----------------------------------------------------------------------
 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
 ----------------------------------------------------------------------
 The biggest lie you can tell yourself is
 When I get what I want I will be happy

I can't really say, but it sounds like what you are asking for is D2/D3,  
thats not really the scope of the dlang-stable project, we just want  
builds of D2 that do not include new features until the community feels  
that those features are stable enough. Which means we will periodically  
roll in the new features, probably on the order of months, which pretty  
typical for 2.x type releases.

If Walter does eventually decide on a D3, then we will probably maintain a  
separate D2 maintenance branch for a while, like all the other big  
compilers, but that's years on down the road.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Leandro Lucarella <luca llucax.com.ar> writes:

Adam Wilson, el 22 de July a las 16:05 me escribiste:
 I can't really say, but it sounds like what you are asking for is
 D2/D3, thats not really the scope of the dlang-stable project, we

Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody
said before in this thread talking about PHP, minor version changes in
the languages should only introduce backward compatible new features. D3
should be allowed to break backward compatibility while D 2.1 should
not. The same is done in Python. In Python is even allowed to break
backward compatibility in very small and are cases, like introducing
a keyword. In those cases the changes are introduced in steps, let's say
in Python 2.5 with is not a keyword and they want to convert it to
a keyword. Then in Python 2.6 you have an option to enable that
behaviour (disabled by default) and in Python 2.7 the new feature will
be enabled by default. Python 2.5.1 can only introduce bugfixes.

This is something I think D needs since ages ago[1], and I thought it was
finally here, but from what you say it doesn't like that way :S

[1] http://www.llucax.com.ar/blog/blog/post/6cac01e1#source-control-and-versioning

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
There is no pain you are receding
A distant ship, smoke on the horizon.
You are only coming through in waves.
Your lips move but I can't hear what you're saying.

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 23 Jul 2012 01:52:57 -0700, Leandro Lucarella <luca llucax.com.ar>  
wrote:

 Adam Wilson, el 22 de July a las 16:05 me escribiste:
 I can't really say, but it sounds like what you are asking for is
 D2/D3, thats not really the scope of the dlang-stable project, we

 Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody
 said before in this thread talking about PHP, minor version changes in
 the languages should only introduce backward compatible new features. D3
 should be allowed to break backward compatibility while D 2.1 should
 not. The same is done in Python. In Python is even allowed to break
 backward compatibility in very small and are cases, like introducing
 a keyword. In those cases the changes are introduced in steps, let's say
 in Python 2.5 with is not a keyword and they want to convert it to
 a keyword. Then in Python 2.6 you have an option to enable that
 behaviour (disabled by default) and in Python 2.7 the new feature will
 be enabled by default. Python 2.5.1 can only introduce bugfixes.

Minor release ARE what we are hoping for, but you'll have to convince  
Walter and company to move to that scheme, it's out of my control. For the  
moment, we will be using a scheme that looks like 2.60.1. Which may be  
what you are talking about. When it's time to roll in the new features and  
breaking fixes the stable release will be bumped to 2.61.1. Is this what  
you are asking for?

 This is something I think D needs since ages ago[1], and I thought it was
 finally here, but from what you say it doesn't like that way :S

 [1]  
 http://www.llucax.com.ar/blog/blog/post/6cac01e1#source-control-and-versioning

 --
 Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
 ----------------------------------------------------------------------
 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
 ----------------------------------------------------------------------
 There is no pain you are receding
 A distant ship, smoke on the horizon.
 You are only coming through in waves.
 Your lips move but I can't hear what you're saying.


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Leandro Lucarella <luca llucax.com.ar> writes:

Adam Wilson, el 23 de July a las 11:07 me escribiste:
 On Mon, 23 Jul 2012 01:52:57 -0700, Leandro Lucarella
 <luca llucax.com.ar> wrote:

Adam Wilson, el 22 de July a las 16:05 me escribiste:
I can't really say, but it sounds like what you are asking for is
D2/D3, thats not really the scope of the dlang-stable project, we

Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody
said before in this thread talking about PHP, minor version changes in
the languages should only introduce backward compatible new features. D3
should be allowed to break backward compatibility while D 2.1 should
not. The same is done in Python. In Python is even allowed to break
backward compatibility in very small and are cases, like introducing
a keyword. In those cases the changes are introduced in steps, let's say
in Python 2.5 with is not a keyword and they want to convert it to
a keyword. Then in Python 2.6 you have an option to enable that
behaviour (disabled by default) and in Python 2.7 the new feature will
be enabled by default. Python 2.5.1 can only introduce bugfixes.

 Minor release ARE what we are hoping for, but you'll have to
 convince Walter and company to move to that scheme, it's out of my

Are you talking about the development model or just the version naming
scheme?

 control. For the moment, we will be using a scheme that looks like
 2.60.1. Which may be what you are talking about. When it's time to
 roll in the new features and breaking fixes the stable release will
 be bumped to 2.61.1. Is this what you are asking for?

I guess. But if after 2.60.1, when you want to make a new "minor"
release with new features, you fork it from, say, 2.064, I would name
that new version, 2.64.1 instead of 2.61.1. Or with that comment you are
implying that there will be "minor" release for each and every official
release? Also, are you planning to drop the leading 0 in the version
number or was just a typo?

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Que barbaridad, este país se va cada ves más pa' tras, más pa' tras...
	-- Sidharta Kiwi

"Adam Wilson" <flyboynw gmail.com> writes:

On Tue, 24 Jul 2012 11:41:52 -0700, Leandro Lucarella <luca llucax.com.a=
r>  =

wrote:

 Adam Wilson, el 23 de July a las 11:07 me escribiste:
 On Mon, 23 Jul 2012 01:52:57 -0700, Leandro Lucarella
 <luca llucax.com.ar> wrote:

Adam Wilson, el 22 de July a las 16:05 me escribiste:
I can't really say, but it sounds like what you are asking for is
D2/D3, thats not really the scope of the dlang-stable project, we

Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody=



said before in this thread talking about PHP, minor version changes =



in
the languages should only introduce backward compatible new features=



.  =

 D3
should be allowed to break backward compatibility while D 2.1 should=



not. The same is done in Python. In Python is even allowed to break
backward compatibility in very small and are cases, like introducing=



a keyword. In those cases the changes are introduced in steps, let's=



  =

 say
in Python 2.5 with is not a keyword and they want to convert it to
a keyword. Then in Python 2.6 you have an option to enable that
behaviour (disabled by default) and in Python 2.7 the new feature wi=



ll
be enabled by default. Python 2.5.1 can only introduce bugfixes.

 Minor release ARE what we are hoping for, but you'll have to
 convince Walter and company to move to that scheme, it's out of my

 Are you talking about the development model or just the version naming=

 scheme?

 control. For the moment, we will be using a scheme that looks like
 2.60.1. Which may be what you are talking about. When it's time to
 roll in the new features and breaking fixes the stable release will
 be bumped to 2.61.1. Is this what you are asking for?

 I guess. But if after 2.60.1, when you want to make a new "minor"
 release with new features, you fork it from, say, 2.064, I would name
 that new version, 2.64.1 instead of 2.61.1. Or with that comment you a=

re
 implying that there will be "minor" release for each and every officia=

l
 release? Also, are you planning to drop the leading 0 in the version
 number or was just a typo?

Yes, the minor will match the minor it's forked from, that is important =
to  =

semantically understanding which release the bugfixes apply to.

There will many releases per minor. So 2.060.1, 2.060.2, etc. I am hopin=
g  =

for packaged releases every week.

I would like to drop the leading 0, but I think it would be confusing to=
  =

people to not have them exactly match D's current scheme.

 --
 Leandro Lucarella (AKA luca)                     http://llucax.com.ar/=

 ----------------------------------------------------------------------=

 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)=

 ----------------------------------------------------------------------=

 Que barbaridad, este pa=EDs se va cada ves m=E1s pa' tras, m=E1s pa' t=

ras...
 	-- Sidharta Kiwi


-- =

Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 09:21:39 -0700, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 16 July 2012 14:00, Marco Leise <Marco.Leise gmx.de> wrote:
 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 As it shows, the beta phase doesn't always catch all regressions in  
 people's code, so I encourage you to do this project and eventually it  
 will be used by GDC and other major from-source projects. By the way:  
 Should this also later become the base for the official zip file  
 download? IIRC Walter wanted to keep track of the DMD downloads from  
 the main web site (no redistribution) and hotfixed versions of D could  
 become increasingly popular.

 --
 Marco

 And what benefits would GDC get from opting to use this rather than
 the normal releases?

The main benefit I could see is the faster cycle focusing on bugs. I don't  
know what GCC's release cycle is (something tells me it's pretty glacial),  
but for any users of your Git-HEAD code, the bug fixes could certainly  
appear faster.

The drawback is that new features may not appear as quickly because we  
will want them to stabilize before we roll them in.

As to whether or not you use it, that's up to you. Our goal with this  
experiment is to build highly reliable (stable) releases on a quicker  
cycle so that we can fix bugs faster. If you think GDC could benefit from  
that, you are welcome to base GDC off these packages.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 16 July 2012 18:31, Adam Wilson <flyboynw gmail.com> wrote:
 On Mon, 16 Jul 2012 09:21:39 -0700, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 16 July 2012 14:00, Marco Leise <Marco.Leise gmx.de> wrote:
 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 As it shows, the beta phase doesn't always catch all regressions in
 people's code, so I encourage you to do this project and eventually it will
 be used by GDC and other major from-source projects. By the way: Should this
 also later become the base for the official zip file download? IIRC Walter
 wanted to keep track of the DMD downloads from the main web site (no
 redistribution) and hotfixed versions of D could become increasingly
 popular.

 --
 Marco

 And what benefits would GDC get from opting to use this rather than
 the normal releases?

 The main benefit I could see is the faster cycle focusing on bugs. I don't
 know what GCC's release cycle is (something tells me it's pretty glacial),
 but for any users of your Git-HEAD code, the bug fixes could certainly
 appear faster.

It's roughly once a year, maybe a little less.  Depends on
regressions, open bugs, etc.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 10:39:04 -0700, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 16 July 2012 18:31, Adam Wilson <flyboynw gmail.com> wrote:
 On Mon, 16 Jul 2012 09:21:39 -0700, Iain Buclaw <ibuclaw ubuntu.com>  
 wrote:

 On 16 July 2012 14:00, Marco Leise <Marco.Leise gmx.de> wrote:
 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 As it shows, the beta phase doesn't always catch all regressions in
 people's code, so I encourage you to do this project and eventually  
 it will
 be used by GDC and other major from-source projects. By the way:  
 Should this
 also later become the base for the official zip file download? IIRC  
 Walter
 wanted to keep track of the DMD downloads from the main web site (no
 redistribution) and hotfixed versions of D could become increasingly
 popular.

 --
 Marco

 And what benefits would GDC get from opting to use this rather than
 the normal releases?

 The main benefit I could see is the faster cycle focusing on bugs. I  
 don't
 know what GCC's release cycle is (something tells me it's pretty  
 glacial),
 but for any users of your Git-HEAD code, the bug fixes could certainly
 appear faster.

 It's roughly once a year, maybe a little less.  Depends on
 regressions, open bugs, etc.

In other words, glacial. :-) But, if it's of interest to you to use the  
stable releases as a basis for GDC we wouldn't mind.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 16 July 2012 19:48, Adam Wilson <flyboynw gmail.com> wrote:
 On Mon, 16 Jul 2012 10:39:04 -0700, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 16 July 2012 18:31, Adam Wilson <flyboynw gmail.com> wrote:
 On Mon, 16 Jul 2012 09:21:39 -0700, Iain Buclaw <ibuclaw ubuntu.com>
 wrote:

 On 16 July 2012 14:00, Marco Leise <Marco.Leise gmx.de> wrote:
 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 As it shows, the beta phase doesn't always catch all regressions in
 people's code, so I encourage you to do this project and eventually it
 will
 be used by GDC and other major from-source projects. By the way: Should
 this
 also later become the base for the official zip file download? IIRC
 Walter
 wanted to keep track of the DMD downloads from the main web site (no
 redistribution) and hotfixed versions of D could become increasingly
 popular.

 --
 Marco

 And what benefits would GDC get from opting to use this rather than
 the normal releases?

 The main benefit I could see is the faster cycle focusing on bugs. I
 don't
 know what GCC's release cycle is (something tells me it's pretty
 glacial),
 but for any users of your Git-HEAD code, the bug fixes could certainly
 appear faster.

 It's roughly once a year, maybe a little less.  Depends on
 regressions, open bugs, etc.

 In other words, glacial. :-) But, if it's of interest to you to use the
 stable releases as a basis for GDC we wouldn't mind.


Will see how it goes.  Typically in the past I have cherry picked
creamy features (__vector support, the recent updates to align) and
merged in any fixes for bugs raised in GDC that are because of, and
fixed in the D frontend prior to merging releases.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 06:00:02 -0700, Marco Leise <Marco.Leise gmx.de> wrote:

 Am Mon, 16 Jul 2012 00:51:16 -0700
 schrieb "Adam Wilson" <flyboynw gmail.com>:

 For the 2.059 release I waited a while until apparent regressions and  
 oddities in Phobos (deprecation warnings) were fixed in the main  
 repository before updating the dmd package for Gentoo. This was quite a  
 bit of manual work collecting, applying and testing patches from GitHub  
 and the bug tracker.
 Will this project be an option for me as a package maintainer? What I  
 need is basically the official dmd zip file (sources, html docs, man  
 pages, bash completion, rdmd binary & co.), but with hotfixes applied at  
 about a week or two after release.
 It seems like your work could make this possible and also allow me to  
 issue a new revision of the package in case of, say a security fix that  
 comes a month after release.
 Last not least, will we get notified about critical/important fixes in  
 the "stable" branch? 'Cause polling is so old-school ;). RSS, news  
 group, email, phone call, anything will do. It looks like GitHub has a  
 commit-RSS-feed, but it would be very noisy on most repositories with  
 messages like "forgot this in last check-in" or "deleted unused  
 file/code", and not every commit warrants a new package.

 As it shows, the beta phase doesn't always catch all regressions in  
 people's code, so I encourage you to do this project and eventually it  
 will be used by GDC and other major from-source projects. By the way:  
 Should this also later become the base for the official zip file  
 download? IIRC Walter wanted to keep track of the DMD downloads from the  
 main web site (no redistribution) and hotfixed versions of D could  
 become increasingly popular.

For the first few packaged releases we aren't going to call this thing  
official. It's just an experiment for the moment. But if it is popular and  
the stability promises we are attempting to make actually hold up, (i.e.  
this experiment actually works) there are plans to revisit this question  
with an eye towards making it official.

However, since the commit list will be bug-fixes and non-breaking  
enhancements only, you may find it easier to work off this list than HEAD.

If you have any more questions on this subject please email Andrei. (You  
can find his email at http://erdani.com/index.php/contact/) He is the  
liaison between this project and the core team.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/16/12 3:51 AM, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a new
 organization on Github called dlang-stable. This organization will be
 responsible for maintaining stable releases of DMD, DRuntime, and Phobos.

[snip]
 Thank you for reading and I hope you enjoy D's new Stable releases!

This is a wonderful initiative that I hope will catch on.

Walter and I are fully behind this experiment. We will make/accept 
changes to the download pages to take into account this new branch.

The main threat I see is bugfixes that depend on code previously 
introduced with now features. I'm not sure how frequent that situation is.

Finally, one suggestion: I suggest you relentlessly work to automate the 
process to the point where you issue e.g. the command

./merge 534d44c979 70dcb958ea

and the script merges in the two specified commits, builds everything, 
runs the test suite, runs the Phobos unittests, and if all worked, 
builds packages and uploads them making them available right away.

That way the team members (busy professionals with many other 
responsibilities) know that once the collective decision to merge a 
commit has been taken, there's virtually no overhead to deploying the 
decision.

I'm a huge fan of automation and I believe we've made progress 
introducing it in dmd's process, but not as much as we could and should.


Good luck!

Andrei

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 09:41:30 -0700, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 7/16/12 3:51 AM, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a new
 organization on Github called dlang-stable. This organization will be
 responsible for maintaining stable releases of DMD, DRuntime, and  
 Phobos.

 [snip]
 Thank you for reading and I hope you enjoy D's new Stable releases!

 This is a wonderful initiative that I hope will catch on.

 Walter and I are fully behind this experiment. We will make/accept  
 changes to the download pages to take into account this new branch.

 The main threat I see is bugfixes that depend on code previously  
 introduced with now features. I'm not sure how frequent that situation  
 is.

 Finally, one suggestion: I suggest you relentlessly work to automate the  
 process to the point where you issue e.g. the command

 ./merge 534d44c979 70dcb958ea

 and the script merges in the two specified commits, builds everything,  
 runs the test suite, runs the Phobos unittests, and if all worked,  
 builds packages and uploads them making them available right away.

The only problem I can see with this is that the build would only for  
whichever OS the merger happens to be running on. A two step process is  
about the best we can do.

./merge does the following
git fetch upstream
git cherry-pick 534d44c979
git cherry-pick 70dcb958ea

If the cherry pick is successful, push to master, which will need to be  
done manually in case any merge conflicts arise.

./build does the following for all projects
git fetch origin
git merge origin/master
make clean -f <system>.mak
make -f <system>.mak
make unittests -f <system>.mak

As for actually putting together the script, my Bash-fu, is not as strong  
as my PowerShell-fu, but with some effort it could be achieved. Both are  
not terribly difficult (expect for the uploading part).

 That way the team members (busy professionals with many other  
 responsibilities) know that once the collective decision to merge a  
 commit has been taken, there's virtually no overhead to deploying the  
 decision.

 I'm a huge fan of automation and I believe we've made progress  
 introducing it in dmd's process, but not as much as we could and should.


 Good luck!

 Andrei


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Jacob Carlborg <doob me.com> writes:

On 2012-07-16 21:37, Adam Wilson wrote:

 The only problem I can see with this is that the build would only for
 whichever OS the merger happens to be running on. A two step process is
 about the best we can do.

 ./merge does the following
 git fetch upstream
 git cherry-pick 534d44c979
 git cherry-pick 70dcb958ea

 If the cherry pick is successful, push to master, which will need to be
 done manually in case any merge conflicts arise.

How would this work? Isn't the whole point of cherry picking to be able 
to choose what to pick from a branch and not picking everything?

 ./build does the following for all projects
 git fetch origin
 git merge origin/master
 make clean -f <system>.mak
 make -f <system>.mak
 make unittests -f <system>.mak

 As for actually putting together the script, my Bash-fu, is not as
 strong as my PowerShell-fu, but with some effort it could be achieved.
 Both are not terribly difficult (expect for the uploading part).

You could use DVM with the "compile" command to build everything.

https://bitbucket.org/doob/dvm

-- 
/Jacob Carlborg

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 23:17:38 -0700, Jacob Carlborg <doob me.com> wrote:

 On 2012-07-16 21:37, Adam Wilson wrote:

 The only problem I can see with this is that the build would only for
 whichever OS the merger happens to be running on. A two step process is
 about the best we can do.

 ./merge does the following
 git fetch upstream
 git cherry-pick 534d44c979
 git cherry-pick 70dcb958ea

 If the cherry pick is successful, push to master, which will need to be
 done manually in case any merge conflicts arise.

 How would this work? Isn't the whole point of cherry picking to be able  
 to choose what to pick from a branch and not picking everything?

Each parameter represents a specific commit ID to pick.

 ./build does the following for all projects
 git fetch origin
 git merge origin/master
 make clean -f <system>.mak
 make -f <system>.mak
 make unittests -f <system>.mak

 As for actually putting together the script, my Bash-fu, is not as
 strong as my PowerShell-fu, but with some effort it could be achieved.
 Both are not terribly difficult (expect for the uploading part).

 You could use DVM with the "compile" command to build everything.

 https://bitbucket.org/doob/dvm

Hmm, this sounds like an interesting method, can it be targeted at any  
repo and if so how? And does it run unittests?

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Mon, 16 Jul 2012 23:24:04 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:
 On Mon, 16 Jul 2012 23:17:38 -0700, Jacob Carlborg <doob me.com>
 wrote:
 
 On 2012-07-16 21:37, Adam Wilson wrote:

 ./build does the following for all projects
 git fetch origin
 git merge origin/master
 make clean -f <system>.mak
 make -f <system>.mak
 make unittests -f <system>.mak

 As for actually putting together the script, my Bash-fu, is not as
 strong as my PowerShell-fu, but with some effort it could be
 achieved. Both are not terribly difficult (expect for the
 uploading part).

 You could use DVM with the "compile" command to build everything.

 https://bitbucket.org/doob/dvm

 
 Hmm, this sounds like an interesting method, can it be targeted at
 any repo and if so how? And does it run unittests?
 

dvm compile <path>

Where <path> is a directory that contains git clones of dmd, phobos,
druntime, and optionally DMD's tools repo. So whatever branch/version is
checked out in that directory, that's what dvm will compile.

It's not very flexible though. For example, it doesn't support
passing arbitrary flags/params to make. RDMD is the only program from
the tools repo it tries to compile. IIRC, it always does a clean
build (or at least to the extent that the "clean" in DMD's
makefiles actually works in the first place - ie, not always perfectly).
It doesn't run unittests, IIRC. And I think there's a thing or two (I
forget what) that it does slightly different between windows and posix
(this was due to the targets and features available/unavailable in
the makefiles being completely fucking different between windows and
posix).

Also, if you're compiling Git sources (instead of recompiling a DMD
release), then it doesn't attempt to recreate the DMD release directory
structure, instead it just puts the bins in <path>/dmd/bin(32|64)/ (or
something like that, don't recall exactly) and sets up sc.ini/dmd.conf
to use the phobos in <path>/phobos, etc.

And then there's a little magic to be aware of: For some stuff (like
windows libs) we don't have source on Github, so it automagically pulls
those in from whatever it detects is the latest official release
(downloading it if necessary).

(tl;dr): Main thing to remember is, as it's written right now, it was
really intended more for people building DMD/Druntime/Phobos themself
and then just using it. Not much thought went into using it to create
packaged releases. So if happens to do what you need it to, then
fantastic, but you should probably try it out first (with the
--verbose flag) and pay close attention to what it's doing. Then see if
that matches what you need. If so, great! If not, then file a ticket,
and with luck maybe Jacob or I may be able to find some time to take
care of it. But I've been busy though, so I can't promise anything :(

Or just deal with bash ;) Either way.

Jacob Carlborg <doob me.com> writes:

On 2012-07-17 08:24, Adam Wilson wrote:

 Each parameter represents a specific commit ID to pick.

So you would pass those to the script?

-- 
/Jacob Carlborg

"Adam Wilson" <flyboynw gmail.com> writes:

On Tue, 17 Jul 2012 02:08:55 -0700, Jacob Carlborg <doob me.com> wrote:

 On 2012-07-17 08:24, Adam Wilson wrote:

 Each parameter represents a specific commit ID to pick.

 So you would pass those to the script?

Yup, I think that's probably the safest way to do it. Given the goals of  
the project, we need to be explicit about which commits we choose so  
forcing the maintainers to write down every commit is good practice.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Jacob Carlborg <doob me.com> writes:

On 2012-07-17 19:04, Adam Wilson wrote:

 Yup, I think that's probably the safest way to do it. Given the goals of
 the project, we need to be explicit about which commits we choose so
 forcing the maintainers to write down every commit is good practice.

Exactly. I took that example a bit too literal, that's what confused me.

-- 
/Jacob Carlborg

Leandro Lucarella <luca llucax.com.ar> writes:

Andrei Alexandrescu, el 16 de July a las 12:41 me escribiste:
 On 7/16/12 3:51 AM, Adam Wilson wrote:
As a result of the D Versioning thread, we have decided to create a new
organization on Github called dlang-stable. This organization will be
responsible for maintaining stable releases of DMD, DRuntime, and Phobos.

 [snip]
Thank you for reading and I hope you enjoy D's new Stable releases!

 This is a wonderful initiative that I hope will catch on.

 Walter and I are fully behind this experiment. We will make/accept
 changes to the download pages to take into account this new branch.

 The main threat I see is bugfixes that depend on code previously
 introduced with now features. I'm not sure how frequent that
 situation is.

 Finally, one suggestion: I suggest you relentlessly work to automate
 the process to the point where you issue e.g. the command

 ./merge 534d44c979 70dcb958ea

 and the script merges in the two specified commits, builds
 everything, runs the test suite, runs the Phobos unittests, and if
 all worked, builds packages and uploads them making them available
 right away.

If he is just going to cherry pick patches, then that can be all
automated using git directly, using a commit hook to test the commit
(and reject it if it fails). Something that everybody should have if
running the test suite weren't so slow :P

What you can do is have a git repository in the test suite server, and
plug git to the autotester, and make it only succeed if the autotester
result was good, the resulting repository will NEVER have a non-working
DMD. This way the testing is asynchronous, so it doesn't bother the
developer, but you also make sure the "good" public repository is always
healthy, something that is not happening now because is the other way
around. Walter first pushes changes to the "good" public repository and
the autotester runs after the commits are published, so there is no way
to undo the commits and fix them privately.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
"The Guinness Book of Records" holds the record for being the most
stolen book in public libraries

Caligo <iteronvexor gmail.com> writes:

Good thing that this is an experiment because creating a new
organization just for something like this is a stupid idea.  Is it so
difficult to create branches and use the features that git provides?!?

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 10:51:59 -0700, Caligo <iteronvexor gmail.com> wrote:

 Good thing that this is an experiment because creating a new
 organization just for something like this is a stupid idea.  Is it so
 difficult to create branches and use the features that git provides?!?

Walter was very uneasy about opening up the primary DMD repo in that  
manner. Maybe if this experiment proves successful he will be more open to  
allowing the work to take place in the primary repo? Let's make this  
project successful and show Walter the true power of Git!

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Caligo <iteronvexor gmail.com> writes:

What?!

All he has to do is create a branch and call it stable, or whatever,
and use cherry-pick to move small stables patches from other branches
to the stable branch.  What's so difficult about that?  I don't get
it.



On Mon, Jul 16, 2012 at 1:03 PM, Adam Wilson <flyboynw gmail.com> wrote:
 On Mon, 16 Jul 2012 10:51:59 -0700, Caligo <iteronvexor gmail.com> wrote:

 Good thing that this is an experiment because creating a new
 organization just for something like this is a stupid idea.  Is it so
 difficult to create branches and use the features that git provides?!?


 Walter was very uneasy about opening up the primary DMD repo in that manner.
 Maybe if this experiment proves successful he will be more open to allowing
 the work to take place in the primary repo? Let's make this project
 successful and show Walter the true power of Git!


 --
 Adam Wilson
 IRC: LightBender
 Project Coordinator
 The Horizon Project
 http://www.thehorizonproject.org/

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 11:18:55 -0700, Caligo <iteronvexor gmail.com> wrote:

 What?!

 All he has to do is create a branch and call it stable, or whatever,
 and use cherry-pick to move small stables patches from other branches
 to the stable branch.  What's so difficult about that?  I don't get
 it.



 On Mon, Jul 16, 2012 at 1:03 PM, Adam Wilson <flyboynw gmail.com> wrote:
 On Mon, 16 Jul 2012 10:51:59 -0700, Caligo <iteronvexor gmail.com>  
 wrote:

 Good thing that this is an experiment because creating a new
 organization just for something like this is a stupid idea.  Is it so
 difficult to create branches and use the features that git provides?!?


 Walter was very uneasy about opening up the primary DMD repo in that  
 manner.
 Maybe if this experiment proves successful he will be more open to  
 allowing
 the work to take place in the primary repo? Let's make this project
 successful and show Walter the true power of Git!


 --
 Adam Wilson
 IRC: LightBender
 Project Coordinator
 The Horizon Project
 http://www.thehorizonproject.org/


He already works on D full-time, this would only slow him down. The other  
option is to open the repos to even more people with master push rights,  
and it was a months-long struggle to convince him to let Kenji, Brad, and  
Don push. Imagine the effort it will take to convince him to let someone  
else in with push rights?

This is a step in the process. Should it prove successful we can reopen  
the organizational discussion, but first, let's just make it work.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Monday, July 16, 2012 13:18:55 Caligo wrote:
 What?!
 
 All he has to do is create a branch and call it stable, or whatever,
 and use cherry-pick to move small stables patches from other branches
 to the stable branch. What's so difficult about that? I don't get
 it.

It takes up his time for him to do it, and I don't think that there's any 
chance whatsoever of him giving someone else commit access to the main dmd 
repository to do this (certainly not at this point). He wasn't interested in 
changing the versioning or branching stuff at all. He agreed to this plan 
(which should be minimally disruptive to him) as an experiment. Depending on 
how it goes, we may change how we deal with the main repo, but for now, we're 
trying this. And since the likely alternative was that we would continue on 
exactly as we have been, this is presumably an improvement for the folks who 
wanted a branch with bug fixes with more frequent releases.

- Jonathan M Davis

Caligo <iteronvexor gmail.com> writes:

Just curious, if Walter is too busy to make DMD more stable, then what
does he spend most of his time on?  I thought we were done with adding
new features to the language (at least for now)?

On Mon, Jul 16, 2012 at 1:29 PM, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 On Monday, July 16, 2012 13:18:55 Caligo wrote:
 What?!

 All he has to do is create a branch and call it stable, or whatever,
 and use cherry-pick to move small stables patches from other branches
 to the stable branch. What's so difficult about that? I don't get
 it.

 It takes up his time for him to do it, and I don't think that there's any
 chance whatsoever of him giving someone else commit access to the main dmd
 repository to do this (certainly not at this point). He wasn't interested in
 changing the versioning or branching stuff at all. He agreed to this plan
 (which should be minimally disruptive to him) as an experiment. Depending on
 how it goes, we may change how we deal with the main repo, but for now, we're
 trying this. And since the likely alternative was that we would continue on
 exactly as we have been, this is presumably an improvement for the folks who
 wanted a branch with bug fixes with more frequent releases.

 - Jonathan M Davis

"Adam Wilson" <flyboynw gmail.com> writes:

On Wed, 18 Jul 2012 22:20:51 -0700, Caligo <iteronvexor gmail.com> wrote:

 Just curious, if Walter is too busy to make DMD more stable, then what
 does he spend most of his time on?  I thought we were done with adding
 new features to the language (at least for now)?

While COFF/x64 support for is technically a new feature, it's also one  
required for the survival of D. x86 is dead on OS X, and dying on Windows  
and Linux. So i'd say that it's pretty important for Walter to get it in  
now.

 On Mon, Jul 16, 2012 at 1:29 PM, Jonathan M Davis <jmdavisProg gmx.com>  
 wrote:
 On Monday, July 16, 2012 13:18:55 Caligo wrote:
 What?!

 All he has to do is create a branch and call it stable, or whatever,
 and use cherry-pick to move small stables patches from other branches
 to the stable branch. What's so difficult about that? I don't get
 it.

 It takes up his time for him to do it, and I don't think that there's  
 any
 chance whatsoever of him giving someone else commit access to the main  
 dmd
 repository to do this (certainly not at this point). He wasn't  
 interested in
 changing the versioning or branching stuff at all. He agreed to this  
 plan
 (which should be minimally disruptive to him) as an experiment.  
 Depending on
 how it goes, we may change how we deal with the main repo, but for now,  
 we're
 trying this. And since the likely alternative was that we would  
 continue on
 exactly as we have been, this is presumably an improvement for the  
 folks who
 wanted a branch with bug fixes with more frequent releases.

 - Jonathan M Davis



-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

"Brad Anderson" <eco gnuk.net> writes:

On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to 
 create a new organization on Github called dlang-stable. This 
 organization will be responsible for maintaining stable 
 releases of DMD, DRuntime, and Phobos.

 So what is a stable release?
 A stable release is a complete build of DMD, DRuntime, and 
 Phobos that ONLY includes the latest bug-fixes and non-breaking 
 enhancements to existing features. It will not include, new 
 features, breaking enhancements, and any other code that the 
 core development team may be working on.

 How often will you release?
 The goal of this project is that D is stable at all times. 
 Therefore, our primary method of release will simply be 
 Git-HEAD. However, we will also make available frequent 
 packaged distributions for those who may be unable to use 
 Git-HEAD. While the exact release cadence is to be determined, 
 we expect it to be more frequent then the current release 
 schedule.

 What if a bug fix breaks my code?
 We will still issue the fix. Fixing the broken behavior is more 
 important than allowing broken code to continue.

 How much will the core team be involved?
 The idea behind this project is that the core team needs to 
 focus on developing D as fast as possible. However, we will 
 coordinate with them as necessary when it is time to pull in 
 the latest work from the development repositories and as any 
 conflicts arise to between the two codebases.

 Is this a fork of D?
 No. Our goal is to follow the development of D perfectly. All 
 the code for the stable releases will be received from the 
 primary repositories. We will simply be cherry-picking the 
 commits we want in the release.

 Will new features ever be merged from the primary repositories?
 Yes. As new features mature, they will be pulled into the 
 stable repos. Precisely when this happens will be a mutual 
 decision by all the developers involved and the community at 
 large.

 I have a bug fix ready to go. Who do I send the pull request to?
 Please send all pull requests to the primary development 
 repositories (D-Programming-Language). From there we will 
 incorporate your fixes as they are merged into the primary 
 repositories.

 I still want to hack on DMD/DRuntme/Phobos. Where do I point my 
 local repositories?
 Then nothing will change for you. You can keep all your 
 existing remotes.

 Who is developing this project?
 For the moment, just myself, with support from Andrei. 
 Although, it would be much appreciated if a few others would 
 step forward as release maintainers to help with the bug fix 
 merges and quality control. If you are interested, I would love 
 to hear from you. You can reply here, send me an email, or 
 contact me on GitHub (handle: LightBender).

 OK, I'm sold! When will the first Stable release be ready?
 Not until after the official release of 2.060. We feel that it 
 is best to this project from a released build of DMD and from 
 then on maintain the stable versions. While it is technically 
 feasible to go back and start from 2.059, the number of bug 
 fixes since then it would make it a gargantuan task. In 
 addition, this period allows us to build-up the release team, 
 synchronize with the core team, and polish our release 
 procedures. After 2.060 we will begin releasing stable versions 
 of D

 Where can I find these stable releases?
 The stable releases are located on GitHub at 
 https://github.com/dlang-stable
 Once the packaged release become available you can expect to 
 see them on http://www.dlang.org/

 If you have any more questions or comments, please reply below 
 and will attempt to answer them to the best of my ability.

 Thank you for reading and I hope you enjoy D's new Stable 
 releases!

Even though I've said this to you in IRC, I'll share here 
publicly that I think this should really be done on a branch in 
the main repo[1].  This setup seems overly complicated and 
confusing (though I recognize you are just working with 
limitations imposed upon you).


I'd like to propose an alternative to this cherry-picking 
solution though which is much easier and plays to git's strengths.

1. Features would be pull requests targeting D-P-L/dmd:master. 
Walter could still push his features directly.

2. Bugfixes would be pull requests targeting D-P-L/dmd:stable. 
Walter could still push his bugfixes directly.

3. D-P-L/dmd:master would periodically merge D-P-L/dmd:stable to 
pull bug fixes in.


This setup requires almost no changes by all contributors. Here 
is a mini guide for contributors outlining the slightly changed 
workflow.

Working on a bugfix:
1. git checkout -b issue-555 stable
2. ... hack hack hack commit ...
3. git push origin issue-555 (Walter can just do `git push origin 
stable` and skip step 4, assuming origin is D-P-L)
4. Make pull request targeting stable

(most people already do this but branch from master)

Working on a feature:
1. git checkout -b constpocalypse master
2. ... hack hack hack commit ...
3. git push origin constpocalypse (Walter can just do `git push 
origin master` and skip step 4)
4. Make pull request targeting master

(this is exactly the workflow people already use)

Even easier is that Walter can work directly on local master and 
stable branches if he'd like to not use topic branches. The only 
thing he'd have to do is `git checkout stable` before working on 
a bug and `git checkout master` before working on a feature. No 
other changes are required.

Periodically someone (anyone with push access) does the following 
to pull bug fixes into master:
1. git checkout master; git merge stable; git push origin;

What is gained by this is that nobody needs to cherry-pick 
bugfixes into a stable repo. Cherry-picking is a substantial 
amount of work (for which I salute you for volunteering to 
undertake). It just seems unnecessary in the world of git.

I'd like to stress one more time that **this is basically no 
additional work for contributors or Walter**.  It's simply 
categorizing changes.

The setup you are planning will work, of course, but I do not 
envy the amount of labor it will require. Whichever way it is 
done is a step in the right direction and I'm glad you are taking 
it on.

Regards,
Brad Anderson

[1] For those that are afraid of less established people having 
push access to the main repo, just remember that the worst thing 
that can happen is history is "lost" through a push -f which can 
be easily undone by anyone else on the team doing their own push 
-f to restore. The hitmen can be dispatched at our leisure.

P.S. This would be my real ideal setup (and is one I use daily) 
but would require more changes: 
http://nvie.com/posts/a-successful-git-branching-model/

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 11:14:07 -0700, Brad Anderson <eco gnuk.net> wrote:

 On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a new  
 organization on Github called dlang-stable. This organization will be  
 responsible for maintaining stable releases of DMD, DRuntime, and  
 Phobos.

 So what is a stable release?
 A stable release is a complete build of DMD, DRuntime, and Phobos that  
 ONLY includes the latest bug-fixes and non-breaking enhancements to  
 existing features. It will not include, new features, breaking  
 enhancements, and any other code that the core development team may be  
 working on.

 How often will you release?
 The goal of this project is that D is stable at all times. Therefore,  
 our primary method of release will simply be Git-HEAD. However, we will  
 also make available frequent packaged distributions for those who may  
 be unable to use Git-HEAD. While the exact release cadence is to be  
 determined, we expect it to be more frequent then the current release  
 schedule.

 What if a bug fix breaks my code?
 We will still issue the fix. Fixing the broken behavior is more  
 important than allowing broken code to continue.

 How much will the core team be involved?
 The idea behind this project is that the core team needs to focus on  
 developing D as fast as possible. However, we will coordinate with them  
 as necessary when it is time to pull in the latest work from the  
 development repositories and as any conflicts arise to between the two  
 codebases.

 Is this a fork of D?
 No. Our goal is to follow the development of D perfectly. All the code  
 for the stable releases will be received from the primary repositories.  
 We will simply be cherry-picking the commits we want in the release.

 Will new features ever be merged from the primary repositories?
 Yes. As new features mature, they will be pulled into the stable repos.  
 Precisely when this happens will be a mutual decision by all the  
 developers involved and the community at large.

 I have a bug fix ready to go. Who do I send the pull request to?
 Please send all pull requests to the primary development repositories  
 (D-Programming-Language). From there we will incorporate your fixes as  
 they are merged into the primary repositories.

 I still want to hack on DMD/DRuntme/Phobos. Where do I point my local  
 repositories?
 Then nothing will change for you. You can keep all your existing  
 remotes.

 Who is developing this project?
 For the moment, just myself, with support from Andrei. Although, it  
 would be much appreciated if a few others would step forward as release  
 maintainers to help with the bug fix merges and quality control. If you  
 are interested, I would love to hear from you. You can reply here, send  
 me an email, or contact me on GitHub (handle: LightBender).

 OK, I'm sold! When will the first Stable release be ready?
 Not until after the official release of 2.060. We feel that it is best  
 to this project from a released build of DMD and from then on maintain  
 the stable versions. While it is technically feasible to go back and  
 start from 2.059, the number of bug fixes since then it would make it a  
 gargantuan task. In addition, this period allows us to build-up the  
 release team, synchronize with the core team, and polish our release  
 procedures. After 2.060 we will begin releasing stable versions of D

 Where can I find these stable releases?
 The stable releases are located on GitHub at  
 https://github.com/dlang-stable
 Once the packaged release become available you can expect to see them  
 on http://www.dlang.org/

 If you have any more questions or comments, please reply below and will  
 attempt to answer them to the best of my ability.

 Thank you for reading and I hope you enjoy D's new Stable releases!

 Even though I've said this to you in IRC, I'll share here publicly that  
 I think this should really be done on a branch in the main repo[1].   
 This setup seems overly complicated and confusing (though I recognize  
 you are just working with limitations imposed upon you).


 I'd like to propose an alternative to this cherry-picking solution  
 though which is much easier and plays to git's strengths.

 1. Features would be pull requests targeting D-P-L/dmd:master. Walter  
 could still push his features directly.

 2. Bugfixes would be pull requests targeting D-P-L/dmd:stable. Walter  
 could still push his bugfixes directly.

 3. D-P-L/dmd:master would periodically merge D-P-L/dmd:stable to pull  
 bug fixes in.


 This setup requires almost no changes by all contributors. Here is a  
 mini guide for contributors outlining the slightly changed workflow.

 Working on a bugfix:
 1. git checkout -b issue-555 stable
 2. ... hack hack hack commit ...
 3. git push origin issue-555 (Walter can just do `git push origin  
 stable` and skip step 4, assuming origin is D-P-L)
 4. Make pull request targeting stable

 (most people already do this but branch from master)

 Working on a feature:
 1. git checkout -b constpocalypse master
 2. ... hack hack hack commit ...
 3. git push origin constpocalypse (Walter can just do `git push origin  
 master` and skip step 4)
 4. Make pull request targeting master

 (this is exactly the workflow people already use)

 Even easier is that Walter can work directly on local master and stable  
 branches if he'd like to not use topic branches. The only thing he'd  
 have to do is `git checkout stable` before working on a bug and `git  
 checkout master` before working on a feature. No other changes are  
 required.

 Periodically someone (anyone with push access) does the following to  
 pull bug fixes into master:
 1. git checkout master; git merge stable; git push origin;

 What is gained by this is that nobody needs to cherry-pick bugfixes into  
 a stable repo. Cherry-picking is a substantial amount of work (for which  
 I salute you for volunteering to undertake). It just seems unnecessary  
 in the world of git.

 I'd like to stress one more time that **this is basically no additional  
 work for contributors or Walter**.  It's simply categorizing changes.

 The setup you are planning will work, of course, but I do not envy the  
 amount of labor it will require. Whichever way it is done is a step in  
 the right direction and I'm glad you are taking it on.

 Regards,
 Brad Anderson

 [1] For those that are afraid of less established people having push  
 access to the main repo, just remember that the worst thing that can  
 happen is history is "lost" through a push -f which can be easily undone  
 by anyone else on the team doing their own push -f to restore. The  
 hitmen can be dispatched at our leisure.

 P.S. This would be my real ideal setup (and is one I use daily) but  
 would require more changes:  
 http://nvie.com/posts/a-successful-git-branching-model/

As I said on IRC, I tend to agree with you that this is a better solution,  
and it certainly plays to git's strengths. However, it's the best  
compromise we could get for now, and something needs to be done for  
everyone waiting on bug-fixes.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/16/12 2:14 PM, Brad Anderson wrote:
[snip]
 What is gained by this is that nobody needs to cherry-pick bugfixes into
 a stable repo. Cherry-picking is a substantial amount of work (for which
 I salute you for volunteering to undertake). It just seems unnecessary
 in the world of git.

 I'd like to stress one more time that **this is basically no additional
 work for contributors or Walter**. It's simply categorizing changes.

 The setup you are planning will work, of course, but I do not envy the
 amount of labor it will require. Whichever way it is done is a step in
 the right direction and I'm glad you are taking it on.

 Regards,
 Brad Anderson

I agree this would be more direct. But I fail to see how Walter 
cherry-picking stuff is "basically no additional work", whereas Adam 
doing essentially the same is an unenviable "amount of labor".

Besides, if Walter is at the same time doing things and deciding their 
category may work worse than a small team making the assessment by 
consensus.


Andrei

"Brad Anderson" <eco gnuk.net> writes:

On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu 
wrote:
 [snip]

 I agree this would be more direct. But I fail to see how Walter 
 cherry-picking stuff is "basically no additional work", whereas 
 Adam doing essentially the same is an unenviable "amount of 
 labor".

He wouldn't be cherry-picking anything. All he'd have to do is a 
checkout (one command) before switching between working on 
features (and by features I mean breaking or major changes) or 
bugs. Adam, on the other hand, would be running git cherry-pick 
over and over dodging changes he determines are too risky to 
include in stable. It also seems like there is a lot more room 
for mistakes to be made doing it this way.

 Besides, if Walter is at the same time doing things and 
 deciding their category may work worse than a small team making 
 the assessment by consensus.

Perhaps. More eyes are better. It just seems like way more work 
than is necessary to accomplish the goal of isolating breaking 
changes so that stable releases can go out easier. The end result 
is all I'm interested in personally since I'm not the one doing 
the work here. I'm not too concerned with whether you use my idea 
or not. I just thought you guys might like to hear an alternative 
that is much easier for you while remaining easy for Walter.

Regards,
Brad Anderson

"Adam Wilson" <flyboynw gmail.com> writes:

On Mon, 16 Jul 2012 13:05:29 -0700, Brad Anderson <eco gnuk.net> wrote:

 On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu wrote:
 [snip]

 I agree this would be more direct. But I fail to see how Walter  
 cherry-picking stuff is "basically no additional work", whereas Adam  
 doing essentially the same is an unenviable "amount of labor".

 He wouldn't be cherry-picking anything. All he'd have to do is a  
 checkout (one command) before switching between working on features (and  
 by features I mean breaking or major changes) or bugs. Adam, on the  
 other hand, would be running git cherry-pick over and over dodging  
 changes he determines are too risky to include in stable. It also seems  
 like there is a lot more room for mistakes to be made doing it this way.

There certainly is more room for mistakes, which is why I think that a  
team-based approach is better. I've also finished putting together some  
scripts to automate the various processes. I think that the merge script  
can especially take a lot of the work and time out of the equation. With a  
single call we can merge as many commits as we feel comfortable with,  
build them, run unittests and push the changes to the server. At this  
point i'll probably spend more time deciding which commits are safe to  
pick than I will actually merging them. At least until I hit a decent  
merge conflict. But hey, everything helps! :-)

Scripts are available here: https://github.com/dlang-stable/utilities

 Besides, if Walter is at the same time doing things and deciding their  
 category may work worse than a small team making the assessment by  
 consensus.

 Perhaps. More eyes are better. It just seems like way more work than is  
 necessary to accomplish the goal of isolating breaking changes so that  
 stable releases can go out easier. The end result is all I'm interested  
 in personally since I'm not the one doing the work here. I'm not too  
 concerned with whether you use my idea or not. I just thought you guys  
 might like to hear an alternative that is much easier for you while  
 remaining easy for Walter.

 Regards,
 Brad Anderson


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

"Jesse Phillips" <Jessekphillips+D gmail.com> writes:

On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu 
wrote:

 I agree this would be more direct. But I fail to see how Walter 
 cherry-picking stuff is "basically no additional work", whereas 
 Adam doing essentially the same is an unenviable "amount of 
 labor".

Well, if things go well, there is a system that could make things 
much simpler. But my thought would that Walter wouldn't need to 
touch the stable branch. The only benefit for the new org is a 
separate set of contributes and separate pull requests.

If this system takes off, while still having a cost to Walter, 
there would be a stable branch which get all the bug fixes and 
the new feature branch. When adding a bug fix just merge the 
stable branch into the feature branch. This won't always be a 
clean merge.

Good luck Adam.

"xenon325" <1 mail.net> writes:

On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu 
wrote:
 I agree this would be more direct. But I fail to see how Walter 
 cherry-picking stuff is "basically no additional work", whereas 
 Adam doing essentially the same is an unenviable "amount of 
 labor".

The difference is Walter (and other developers) knows his changes 
intimately.

The whole point of dlang-stable is to deliver bug-fixes more 
quickly. To make this work developers should fix bugs in separate 
branch, and do separate commit (IIUC, which I'm not quite sure). 
So it's virtually zero effort on their side.

On the other hand, Adam must look at this code really closely. 
Now add to the picture other developers whom changes Adam will 
need to examine too. All of his D-love energy will be consumed by 
maybe 5 developers. And I don't understand what benefits are 
(given zero effort for developers).

This doesn't scale. At some point number of the compiler 
developers will be 100 times then it is now. And that will 
require 100 times more Adams to handle the stream.


 Besides, if Walter is at the same time doing things and 
 deciding their category may work worse than a small team making 
 the assessment by consensus.

That (few people reviewing same patches) would scale even worse.


B.t.w. how does Linux kernel people handle this ?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday, July 19, 2012 00:20:51 Caligo wrote:
 Just curious, if Walter is too busy to make DMD more stable, then what
 does he spend most of his time on?  I thought we were done with adding
 new features to the language (at least for now)?

No one said anything about Walter not making dmd more stable. What he doesn't 
have time to spend on is managing a separate branch which includes only bug 
fixes. He spends lots of time on both bug fixing and new stuff, and his skills 
are valuable enough that his time is better spent on actually coding than 
dealing with branch management.

Currently, he's focusing on adding COFF support for Windows, which will make 
it possible to link using Microsoft's linker and generate 64-bit binaries. 
It's not a new feature in the sense that the language itself is gaining a 
feature, but it _is_ new functionality for the compiler.

- Jonathan M Davis

Don Clugston <dac nospam.com> writes:

On 16/07/12 09:51, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a new
 organization on Github called dlang-stable. This organization will be
 responsible for maintaining stable releases of DMD, DRuntime, and Phobos.

 So what is a stable release?
 A stable release is a complete build of DMD, DRuntime, and Phobos that
 ONLY includes the latest bug-fixes and non-breaking enhancements to
 existing features. It will not include, new features, breaking
 enhancements, and any other code that the core development team may be
 working on.

I'm not actually sure what this means. I fear that it may be motivated 
by an inaccurate assessment of the current situation.

The existing instability comes almost entirely from Phobos, not from the 
compiler. Historically there have been very few instances where you 
might want to choose an older compiler in preference to the latest release.

As I've said before, the one time when a language change caused 
*massive* instability was in the attempt to move AAs from language to 
library -- even though that wasn't even supposed to affect existing code 
in any way. The other thing that typically causes regressions is fixes 
to forward-reference bugs.

Historically, addition of new language features has NOT caused 
instability. What has been true is that features have been added to the 
compiler before they were really usable, but they have not broken 
existing code. Fairly obviously the 64 bit compiler was quite buggy when 
initially released. But even that massive change wasn't much more buggy 
than the library AAs! So I am not sure that you can correctly guess 
where instability will come from.

In summary -- I would not expect your stable DMD to be very different 
from the normal DMD. Phobos is where the instability issue is.

"Adam Wilson" <flyboynw gmail.com> writes:

On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston <dac nospam.com> wrote:

 On 16/07/12 09:51, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a new
 organization on Github called dlang-stable. This organization will be
 responsible for maintaining stable releases of DMD, DRuntime, and  
 Phobos.

 So what is a stable release?
 A stable release is a complete build of DMD, DRuntime, and Phobos that
 ONLY includes the latest bug-fixes and non-breaking enhancements to
 existing features. It will not include, new features, breaking
 enhancements, and any other code that the core development team may be
 working on.

 I'm not actually sure what this means. I fear that it may be motivated  
 by an inaccurate assessment of the current situation.

 The existing instability comes almost entirely from Phobos, not from the  
 compiler. Historically there have been very few instances where you  
 might want to choose an older compiler in preference to the latest  
 release.

 As I've said before, the one time when a language change caused  
 *massive* instability was in the attempt to move AAs from language to  
 library -- even though that wasn't even supposed to affect existing code  
 in any way. The other thing that typically causes regressions is fixes  
 to forward-reference bugs.

 Historically, addition of new language features has NOT caused  
 instability. What has been true is that features have been added to the  
 compiler before they were really usable, but they have not broken  
 existing code. Fairly obviously the 64 bit compiler was quite buggy when  
 initially released. But even that massive change wasn't much more buggy  
 than the library AAs! So I am not sure that you can correctly guess  
 where instability will come from.

 In summary -- I would not expect your stable DMD to be very different  
 from the normal DMD. Phobos is where the instability issue is.

There are three issues we are trying to address:

The first and largest issue is the long and variable periods between DMD  
releases. By the end of the 2.060 Beta period there will have been at  
least 3.5 months since 2.059. And while for the people who can use Git  
HEAD this may not be a problem, there are MANY who, for whatever reason,  
must use the released versions. For them the 314 resolved issues and  
dozens of regressions fixed are a tantalizingly out of reach.

The second issue is the root of the first. Much of the delay was caused by  
Walter starting to work on COFF. Which brings up the second point of  
contention in the community, a significant number of bugs are typically  
introduced when this new work is introduced precisely because it's not  
ready, and the effort required to make it stable would significantly delay  
the release, which loops back to the first problem of release cadence.  
Yes, D is more stable than ever, but we keep breaking it to push bugfix  
builds because the community starts to get restless without bugfixes.  
Which is the whole reason this stable project got started.

The third is the result of the first two. The slow release cadence  
combined with the requirement to push new features along side bug-fixes is  
seriously holding back the growth of the D community. There is a feeling  
out here that D is lurching unsteadily forward when it should be smoothly  
accelerating and most of this feeling is rooted in the prior two causes.  
This has a very corrosive effect on the community and particularly their  
willingness to contribute.

The goal of dlang-stable is to provide the primary development team (you!)  
with the ability to release whenever you feel a new feature or enhancement  
is stable enough to be released WITHOUT having to worry about the ever  
growing number of bugfixes that are backlogged in with the new features.  
We are trying to reduce the bugfix pressure so that you can focus on  
delivering high-quality code when it's ready.

The community WANTS these new features, but we CAN'T wait 3.5 months (or  
more!) for the bugfixes that are baked in with them. We have to provide  
BOTH.

That is dlang-stable.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Don Clugston <dac nospam.com> writes:

On 24/07/12 19:27, Adam Wilson wrote:
 On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston <dac nospam.com> wrote:

 On 16/07/12 09:51, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a new
 organization on Github called dlang-stable. This organization will be
 responsible for maintaining stable releases of DMD, DRuntime, and
 Phobos.

 So what is a stable release?
 A stable release is a complete build of DMD, DRuntime, and Phobos that
 ONLY includes the latest bug-fixes and non-breaking enhancements to
 existing features. It will not include, new features, breaking
 enhancements, and any other code that the core development team may be
 working on.

 I'm not actually sure what this means. I fear that it may be motivated
 by an inaccurate assessment of the current situation.

 The existing instability comes almost entirely from Phobos, not from
 the compiler. Historically there have been very few instances where
 you might want to choose an older compiler in preference to the latest
 release.

 As I've said before, the one time when a language change caused
 *massive* instability was in the attempt to move AAs from language to
 library -- even though that wasn't even supposed to affect existing
 code in any way. The other thing that typically causes regressions is
 fixes to forward-reference bugs.

 Historically, addition of new language features has NOT caused
 instability. What has been true is that features have been added to
 the compiler before they were really usable, but they have not broken
 existing code. Fairly obviously the 64 bit compiler was quite buggy
 when initially released. But even that massive change wasn't much more
 buggy than the library AAs! So I am not sure that you can correctly
 guess where instability will come from.

 In summary -- I would not expect your stable DMD to be very different
 from the normal DMD. Phobos is where the instability issue is.

 There are three issues we are trying to address:

 The first and largest issue is the long and variable periods between DMD
 releases. By the end of the 2.060 Beta period there will have been at
 least 3.5 months since 2.059. And while for the people who can use Git
 HEAD this may not be a problem, there are MANY who, for whatever reason,
 must use the released versions. For them the 314 resolved issues and
 dozens of regressions fixed are a tantalizingly out of reach.

I agree, but the fact that has happened, is just plain silly. There is 
no sensible reason why this happened. We were in fact ready for a 
release nearly two months ago. Somehow it did not happen. That 
ridiculous situation is the thing that needs to be addressed, IMHO.

In fact, I see no reason why we couldn't do a release every month.

 The second issue is the root of the first. Much of the delay was caused
 by Walter starting to work on COFF. Which brings up the second point of
 contention in the community, a significant number of bugs are typically
 introduced when this new work is introduced precisely because it's not
 ready,

I do not believe that at all. Where is the evidence for it?

 The third is the result of the first two. The slow release cadence
 combined with the requirement to push new features along side bug-fixes
 is seriously holding back the growth of the D community. There is a
 feeling out here that D is lurching unsteadily forward when it should be
 smoothly accelerating and most of this feeling is rooted in the prior
 two causes. This has a very corrosive effect on the community and
 particularly their willingness to contribute.

 The goal of dlang-stable is to provide the primary development team
 (you!) with the ability to release whenever you feel a new feature or
 enhancement is stable enough to be released WITHOUT having to worry
 about the ever growing number of bugfixes that are backlogged in with
 the new features. We are trying to reduce the bugfix pressure so that
 you can focus on delivering high-quality code when it's ready.

 The community WANTS these new features, but we CAN'T wait 3.5 months (or
 more!) for the bugfixes that are baked in with them. We have to provide
 BOTH.

We don't need this complexity. The solution is *trivial*. We just need 
to decide in advance that we will target a release every X weeks, and 
that it should be delayed only for reasons of stability.

An agreement is ALL that is required. But despite repeated requests, I 
have never been able to get any traction on the idea.
Instead, people propose all kinds of crazy technical solutions, the most 
recent ones being changes to bugzilla, trello, and now dlang-stable.

If we say, "There will be a new compiler release every 8 weeks", the 
problem is solved. Seriously. That one-off agreement is ALL that is 
required.

But the D community finds it easier to implement a new 64-bit Windows 
compiler, than to make a agreement on a short-term release schedule. 
We're a strange bunch, I tell you.

Jacob Carlborg <doob me.com> writes:

On 2012-07-25 09:43, Don Clugston wrote:

 We don't need this complexity. The solution is *trivial*. We just need
 to decide in advance that we will target a release every X weeks, and
 that it should be delayed only for reasons of stability.

Yeah, but what happens when Walter or someone else decides to start a 
big project, i.e. implementing COFF support, a week before release? We 
end up with a bunch of half finished things.

A solution to this would be to create a new branch or not push the 
changes upstream. Although I don't understand why Walter doesn't already 
do this.

 An agreement is ALL that is required. But despite repeated requests, I
 have never been able to get any traction on the idea.
 Instead, people propose all kinds of crazy technical solutions, the most
 recent ones being changes to bugzilla, trello, and now dlang-stable.

 If we say, "There will be a new compiler release every 8 weeks", the
 problem is solved. Seriously. That one-off agreement is ALL that is
 required.

Apparently it seems very difficult to agree upon, since it hasn't 
happened. The releases just pop up at random.

-- 
/Jacob Carlborg

Don Clugston <dac nospam.com> writes:

On 25/07/12 14:32, Jacob Carlborg wrote:
 On 2012-07-25 09:43, Don Clugston wrote:

 We don't need this complexity. The solution is *trivial*. We just need
 to decide in advance that we will target a release every X weeks, and
 that it should be delayed only for reasons of stability.

 Yeah, but what happens when Walter or someone else decides to start a
 big project, i.e. implementing COFF support, a week before release? We
 end up with a bunch of half finished things.

If we had an agreed release cycle, it would not happen. The release 
cycle would be a higher authority than any single person, even Walter.

 A solution to this would be to create a new branch or not push the
 changes upstream. Although I don't understand why Walter doesn't already
 do this.

 An agreement is ALL that is required. But despite repeated requests, I
 have never been able to get any traction on the idea.
 Instead, people propose all kinds of crazy technical solutions, the most
 recent ones being changes to bugzilla, trello, and now dlang-stable.

 If we say, "There will be a new compiler release every 8 weeks", the
 problem is solved. Seriously. That one-off agreement is ALL that is
 required.

 Apparently it seems very difficult to agree upon, since it hasn't
 happened. The releases just pop up at random.

I have tried many times, without success. I've never succeeded in 
getting more than two or three people interested.

Jacob Carlborg <doob me.com> writes:

On 2012-07-25 14:47, Don Clugston wrote:

 If we had an agreed release cycle, it would not happen. The release
 cycle would be a higher authority than any single person, even Walter.

I don't think it's that simple. We would also need some kind of window 
when you're allowed to commit new things to the repository. This window 
could end one or two weeks before the release should be out. Otherwise 
people will think that just "their small commit" can be added just a day 
before the release day "since it won't cause any problems".

-- 
/Jacob Carlborg

Leandro Lucarella <luca llucax.com.ar> writes:

Jacob Carlborg, el 25 de July a las 17:08 me  escribiste:
 On 2012-07-25 14:47, Don Clugston wrote:

If we had an agreed release cycle, it would not happen. The release
cycle would be a higher authority than any single person, even Walter.

 I don't think it's that simple. We would also need some kind of
 window when you're allowed to commit new things to the repository.

Like Linux's "merge window". It's simple, you accept new features just
for a short period of time, and then just work on stabilizing things and
bug fixing.

That said, I wish D never include new features (as a language) unless
there is a stable branch, which is still maintained for some time and
don't get them.

Bare in mind that DMD != D Programming Language, so adding new features
to DMD is perfectly fine for me, like COFF or a new architecture. As
long as it doesn't break old code is fine.

 This window could end one or two weeks before the release should be
 out. Otherwise people will think that just "their small commit" can
 be added just a day before the release day "since it won't cause any
 problems".

The window doesn't need to be too long, you can always develop new
features in parallel in your own branch while a release is being
stabilized. You don't have to wait for the merge window to open to
develop new features, is just a *merge* window, when it's open you're
new feature should be done already, the window is only there to say
"hey! Please pull from this branch!".

If you want a monthly release, I'd say a 1 week merge window is enough
(leaves you with 3 weeks for stabilization).

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
<mazzi> Estoy en berlin
<mazzi> Es como palermo
<mazzi> Pero
<mazzi> Mas copado
<mazzi> Muuucho menos careta

Jacob Carlborg <doob me.com> writes:

On 2012-07-25 19:17, Leandro Lucarella wrote:

 Like Linux's "merge window". It's simple, you accept new features just
 for a short period of time, and then just work on stabilizing things and
 bug fixing.

Yes, exactly.

 That said, I wish D never include new features (as a language) unless
 there is a stable branch, which is still maintained for some time and
 don't get them.

I don't mind new features once in a while, if it's done correctly.

 Bare in mind that DMD != D Programming Language, so adding new features
 to DMD is perfectly fine for me, like COFF or a new architecture. As
 long as it doesn't break old code is fine.

I agree. That is another, slightly related problem with D. Currently, D 
programming language == DMD == Druntime == Phobos. They're all to 
closely connected. There should be possible to just to a release of 
Phobos, for example. Or a release of DMD with just bug fixes.

 The window doesn't need to be too long, you can always develop new
 features in parallel in your own branch while a release is being
 stabilized. You don't have to wait for the merge window to open to
 develop new features, is just a *merge* window, when it's open you're
 new feature should be done already, the window is only there to say
 "hey! Please pull from this branch!".

Exactly.

 If you want a monthly release, I'd say a 1 week merge window is enough
 (leaves you with 3 weeks for stabilization).

Yes, the merge window depends on how often we release.

-- 
/Jacob Carlborg

Leandro Lucarella <luca llucax.com.ar> writes:

Jacob Carlborg, el 25 de July a las 14:32 me escribiste:
 On 2012-07-25 09:43, Don Clugston wrote:

We don't need this complexity. The solution is *trivial*. We just need
to decide in advance that we will target a release every X weeks, and
that it should be delayed only for reasons of stability.

 Yeah, but what happens when Walter or someone else decides to start
 a big project, i.e. implementing COFF support, a week before
 release? We end up with a bunch of half finished things.

 A solution to this would be to create a new branch or not push the
 changes upstream. Although I don't understand why Walter doesn't
 already do this.

The same reason he is pushing "revert ..." patches all the time, he is
using git as if it were svn :P

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Estoy de acuerdo en que el hombre es igual a los ojos de Dios..., pero
hay algunos que, siendo negros, hacen uso de lo que no les corresponde.
Eso Dios no lo ve.
	-- Ricardo Vaporeso. Manifestación en Mississippi a favor de
		los blancos, 1923.

Jacob Carlborg <doob me.com> writes:

On 2012-07-25 19:08, Leandro Lucarella wrote:

 The same reason he is pushing "revert ..." patches all the time, he is
 using git as if it were svn :P

I'm suspecting that.

-- 
/Jacob Carlborg

"Adam Wilson" <flyboynw gmail.com> writes:

On Wed, 25 Jul 2012 00:43:23 -0700, Don Clugston <dac nospam.com> wrote:

 On 24/07/12 19:27, Adam Wilson wrote:
 On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston <dac nospam.com> wrote:

 On 16/07/12 09:51, Adam Wilson wrote:
 As a result of the D Versioning thread, we have decided to create a  
 new
 organization on Github called dlang-stable. This organization will be
 responsible for maintaining stable releases of DMD, DRuntime, and
 Phobos.

 So what is a stable release?
 A stable release is a complete build of DMD, DRuntime, and Phobos that
 ONLY includes the latest bug-fixes and non-breaking enhancements to
 existing features. It will not include, new features, breaking
 enhancements, and any other code that the core development team may be
 working on.

 I'm not actually sure what this means. I fear that it may be motivated
 by an inaccurate assessment of the current situation.

 The existing instability comes almost entirely from Phobos, not from
 the compiler. Historically there have been very few instances where
 you might want to choose an older compiler in preference to the latest
 release.

 As I've said before, the one time when a language change caused
 *massive* instability was in the attempt to move AAs from language to
 library -- even though that wasn't even supposed to affect existing
 code in any way. The other thing that typically causes regressions is
 fixes to forward-reference bugs.

 Historically, addition of new language features has NOT caused
 instability. What has been true is that features have been added to
 the compiler before they were really usable, but they have not broken
 existing code. Fairly obviously the 64 bit compiler was quite buggy
 when initially released. But even that massive change wasn't much more
 buggy than the library AAs! So I am not sure that you can correctly
 guess where instability will come from.

 In summary -- I would not expect your stable DMD to be very different
 from the normal DMD. Phobos is where the instability issue is.

 There are three issues we are trying to address:

 The first and largest issue is the long and variable periods between DMD
 releases. By the end of the 2.060 Beta period there will have been at
 least 3.5 months since 2.059. And while for the people who can use Git
 HEAD this may not be a problem, there are MANY who, for whatever reason,
 must use the released versions. For them the 314 resolved issues and
 dozens of regressions fixed are a tantalizingly out of reach.

 I agree, but the fact that has happened, is just plain silly. There is  
 no sensible reason why this happened. We were in fact ready for a  
 release nearly two months ago. Somehow it did not happen. That  
 ridiculous situation is the thing that needs to be addressed, IMHO.

 In fact, I see no reason why we couldn't do a release every month.

 The second issue is the root of the first. Much of the delay was caused
 by Walter starting to work on COFF. Which brings up the second point of
 contention in the community, a significant number of bugs are typically
 introduced when this new work is introduced precisely because it's not
 ready,

 I do not believe that at all. Where is the evidence for it?

 The third is the result of the first two. The slow release cadence
 combined with the requirement to push new features along side bug-fixes
 is seriously holding back the growth of the D community. There is a
 feeling out here that D is lurching unsteadily forward when it should be
 smoothly accelerating and most of this feeling is rooted in the prior
 two causes. This has a very corrosive effect on the community and
 particularly their willingness to contribute.

 The goal of dlang-stable is to provide the primary development team
 (you!) with the ability to release whenever you feel a new feature or
 enhancement is stable enough to be released WITHOUT having to worry
 about the ever growing number of bugfixes that are backlogged in with
 the new features. We are trying to reduce the bugfix pressure so that
 you can focus on delivering high-quality code when it's ready.

 The community WANTS these new features, but we CAN'T wait 3.5 months (or
 more!) for the bugfixes that are baked in with them. We have to provide
 BOTH.

 We don't need this complexity. The solution is *trivial*. We just need  
 to decide in advance that we will target a release every X weeks, and  
 that it should be delayed only for reasons of stability.

 An agreement is ALL that is required. But despite repeated requests, I  
 have never been able to get any traction on the idea.
 Instead, people propose all kinds of crazy technical solutions, the most  
 recent ones being changes to bugzilla, trello, and now dlang-stable.

 If we say, "There will be a new compiler release every 8 weeks", the  
 problem is solved. Seriously. That one-off agreement is ALL that is  
 required.

 But the D community finds it easier to implement a new 64-bit Windows  
 compiler, than to make a agreement on a short-term release schedule.  
 We're a strange bunch, I tell you.

I don't think a rigid release schedule has ever worked in software  
development. Linus is world-renowned for releasing at what looks like  
utterly random intervals and I know of very little software that ships on  
a strict time based cadence. It almost ALWAYS slips for some reason or the  
other.

I guess my point is that it isn't as easy as making the schedule the final  
arbiter because it is an attempt to deny that the real world exists. What  
if Walter is on vacation (I don't know if he believes in vacations but,  
bear with me) during release week? What then? Do we demand that he  
organize is life around our precious release schedule?

Also, what about projects that absolutely cannot be completed in under X  
weeks? Do we just leave the code in the release, half working, waiting to  
spread all KINDS of bugs?

That sounds to almost everyone here like a recipe for complete disaster.  
More to the point, I know of no successful project, OSS or Commercial,  
that follows this model. Development and Stable releases are a staple of  
the Open-Source world, and it would behoove us to learn from those who  
went before us. If the model doesn't work, why is it nearly universal? Do  
we really think that we are better than Linux or LibreOffice or Java?

I would make an argument that such thinking is one of the things holding D  
back. The industry is crying out for something like D ... just look at the  
proliferation of new native languages that attempt to address the problems  
of C/C++ in their own ways; and yet, D, with it's clean syntax and  
multi-paradigm capabilities is a bit player.

If I had my way, this would all be handled by the dev team via Git  
branching. But it appears that Walter was unwilling to do the work, so we  
the community have stepped up. It is an entirely predictable outcome of  
the very real pains felt in the community. And dlang-stable is essentially  
a branch of the HEAD repos, just with more process in between. Less  
efficient, certainly. Will it fail ... I doubt it, but let's find out.

And seriously, the flexibility to release whenever and not be pressured by  
the community at large because we've gone so long with bugfixes should be  
freeing to the dev team, not constricting!

As a side note, 64-bit support is critical to the long term viability of  
D. 32-bit is a rapidly dying concern, once ARM 64-bit goes mainstream the  
party is over. 32-bit will be archaic by the end of the decade, and out of  
common usage well before then.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Jacob Carlborg <doob me.com> writes:

 I don't think a rigid release schedule has ever worked in software
 development. Linus is world-renowned for releasing at what looks like
 utterly random intervals and I know of very little software that ships
 on a strict time based cadence. It almost ALWAYS slips for some reason
 or the other.

 I guess my point is that it isn't as easy as making the schedule the
 final arbiter because it is an attempt to deny that the real world
 exists. What if Walter is on vacation (I don't know if he believes in
 vacations but, bear with me) during release week? What then? Do we
 demand that he organize is life around our precious release schedule?

You can at least come to an official agreement that we should release on 
a given interval. Then we don't need to stop the world to make that 
happened. Sometimes it will be delayed and that would be acceptable. If 
we do have a release schedule and Walter, for example, knows he will be 
on vacation during the release week. We can plan ahead and annoyance 
that the next release will be delayed or skipped.

 Also, what about projects that absolutely cannot be completed in under X
 weeks? Do we just leave the code in the release, half working, waiting
 to spread all KINDS of bugs?

No, no, no. That's another problem. Don't commit anything to 
upstream/master that isn't finished. I don't know why Walter does that. 
Does he not have his own fork? Why not create a new branch at least?

 That sounds to almost everyone here like a recipe for complete disaster.
 More to the point, I know of no successful project, OSS or Commercial,
 that follows this model. Development and Stable releases are a staple of
 the Open-Source world, and it would behoove us to learn from those who
 went before us. If the model doesn't work, why is it nearly universal?
 Do we really think that we are better than Linux or LibreOffice or Java?

 I would make an argument that such thinking is one of the things holding
 D back. The industry is crying out for something like D ... just look at
 the proliferation of new native languages that attempt to address the
 problems of C/C++ in their own ways; and yet, D, with it's clean syntax
 and multi-paradigm capabilities is a bit player.

 If I had my way, this would all be handled by the dev team via Git
 branching. But it appears that Walter was unwilling to do the work, so
 we the community have stepped up. It is an entirely predictable outcome
 of the very real pains felt in the community. And dlang-stable is
 essentially a branch of the HEAD repos, just with more process in
 between. Less efficient, certainly. Will it fail ... I doubt it, but
 let's find out.

 And seriously, the flexibility to release whenever and not be pressured
 by the community at large because we've gone so long with bugfixes
 should be freeing to the dev team, not constricting!

 As a side note, 64-bit support is critical to the long term viability of
 D. 32-bit is a rapidly dying concern, once ARM 64-bit goes mainstream
 the party is over. 32-bit will be archaic by the end of the decade, and
 out of common usage well before then.

Agree.

-- 
/Jacob Carlborg

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday, July 26, 2012 08:35:26 Jacob Carlborg wrote:
 I don't think a rigid release schedule has ever worked in software
 development. Linus is world-renowned for releasing at what looks like
 utterly random intervals and I know of very little software that ships
 on a strict time based cadence. It almost ALWAYS slips for some reason
 or the other.
 
 I guess my point is that it isn't as easy as making the schedule the
 final arbiter because it is an attempt to deny that the real world
 exists. What if Walter is on vacation (I don't know if he believes in
 vacations but, bear with me) during release week? What then? Do we
 demand that he organize is life around our precious release schedule?

 
 You can at least come to an official agreement that we should release on
 a given interval. Then we don't need to stop the world to make that
 happened. Sometimes it will be delayed and that would be acceptable. If
 we do have a release schedule and Walter, for example, knows he will be
 on vacation during the release week. We can plan ahead and annoyance
 that the next release will be delayed or skipped.
 
 Also, what about projects that absolutely cannot be completed in under X
 weeks? Do we just leave the code in the release, half working, waiting
 to spread all KINDS of bugs?

 
 No, no, no. That's another problem. Don't commit anything to
 upstream/master that isn't finished. I don't know why Walter does that.
 Does he not have his own fork? Why not create a new branch at least?

There are a number of things that we could do to improve our release process - 
a number of them revolving around taking proper advantage of git (though not 
all) - but actually effecting those kind of changes has been incredibly
difficult 
as Don has pointed out. So, while there are a number of things that we _could_ 
do (and probably _should_ do), the fact that Walter has agreed to this scheme 
with dlang-stable is actually _huge_. It may help open the door to other 
changes to the release process (like branching for a beta). AFAIK, Walter 
never branches for _anything_, though maybe he does have branches of some kind 
on his computer.

- Jonathan M Davis

Jacob Carlborg <doob me.com> writes:

On 2012-07-26 08:47, Jonathan M Davis wrote:

 There are a number of things that we could do to improve our release process -
 a number of them revolving around taking proper advantage of git (though not
 all) - but actually effecting those kind of changes has been incredibly
difficult
 as Don has pointed out. So, while there are a number of things that we _could_
 do (and probably _should_ do), the fact that Walter has agreed to this scheme
 with dlang-stable is actually _huge_. It may help open the door to other
 changes to the release process (like branching for a beta). AFAIK, Walter
 never branches for _anything_, though maybe he does have branches of some kind
 on his computer.

Yeah, hopefully it will open the door for more changes.

-- 
/Jacob Carlborg