www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Coming Soon: Stable D Releases!

reply "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/
Jul 16 2012
next sibling parent reply 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
Jul 16 2012
parent "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/
Jul 16 2012
prev sibling next sibling parent reply "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.
Jul 16 2012
parent "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/
Jul 16 2012
prev sibling next sibling parent reply 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.
Jul 16 2012
parent reply "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/
Jul 16 2012
parent reply 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)
Jul 21 2012
parent "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/
Jul 21 2012
prev sibling next sibling parent reply "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
Jul 16 2012
parent "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/
Jul 16 2012
prev sibling next sibling parent reply 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
Jul 16 2012
next sibling parent reply 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';
Jul 16 2012
next sibling parent reply 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
Jul 16 2012
parent reply "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
Jul 16 2012
parent reply "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/
Jul 16 2012
next sibling parent reply 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';
Jul 16 2012
parent "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/
Jul 16 2012
prev sibling parent reply 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
Jul 21 2012
parent reply "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/
Jul 21 2012
parent reply 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
Jul 22 2012
parent reply "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/
Jul 22 2012
parent reply 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.
Jul 23 2012
parent reply "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/
Jul 23 2012
parent reply 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
Jul 24 2012
parent "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/
Jul 24 2012
prev sibling parent reply "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/
Jul 16 2012
parent reply 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';
Jul 16 2012
parent reply "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/
Jul 16 2012
parent 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';
Jul 16 2012
prev sibling parent "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/
Jul 16 2012
prev sibling next sibling parent reply 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
Jul 16 2012
next sibling parent reply "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/
Jul 16 2012
parent reply 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
Jul 16 2012
parent reply "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/
Jul 16 2012
next sibling parent 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.
Jul 17 2012
prev sibling parent reply 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
Jul 17 2012
parent reply "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/
Jul 17 2012
parent 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
Jul 17 2012
prev sibling parent 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
Jul 21 2012
prev sibling next sibling parent reply 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?!?
Jul 16 2012
parent reply "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/
Jul 16 2012
next sibling parent reply 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/
Jul 16 2012
parent "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/
Jul 16 2012
prev sibling next sibling parent "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
Jul 16 2012
prev sibling parent reply 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
Jul 18 2012
parent "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/
Jul 18 2012
prev sibling next sibling parent reply "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/
Jul 16 2012
next sibling parent "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/
Jul 16 2012
prev sibling parent reply 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
Jul 16 2012
next sibling parent reply "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
Jul 16 2012
parent "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/
Jul 22 2012
prev sibling next sibling parent "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.
Jul 18 2012
prev sibling parent "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 ?
Jul 24 2012
prev sibling next sibling parent 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
Jul 18 2012
prev sibling parent reply 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.
Jul 24 2012
parent reply "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/
Jul 24 2012
parent reply 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.
Jul 25 2012
next sibling parent reply 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
Jul 25 2012
next sibling parent reply 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.
Jul 25 2012
parent reply 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
Jul 25 2012
parent reply 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
Jul 25 2012
parent 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
Jul 25 2012
prev sibling parent reply 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.
Jul 25 2012
parent 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
Jul 25 2012
prev sibling parent reply "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/
Jul 25 2012
parent reply 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
Jul 25 2012
parent reply 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
Jul 25 2012
parent 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
Jul 26 2012