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