July 16, 2012
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
July 16, 2012
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/
July 16, 2012
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';
July 16, 2012
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/
July 16, 2012
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?!?
July 16, 2012
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 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

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/
July 16, 2012
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.

> 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-pick 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ántico, querés nadar a mi lado.
> Y me estás ahogando.


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 16, 2012
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/
July 16, 2012
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/
July 16, 2012
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/