Coming Soon: Stable D Releases!

Adam Wilson flyboynw at gmail.com
Mon Jul 16 11:37:23 PDT 2012


On Mon, 16 Jul 2012 11:14:07 -0700, Brad Anderson <eco at 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/


More information about the Digitalmars-d-announce mailing list