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