Coming Soon: Stable D Releases!

[Brad Anderson]

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/