On 11-12-2012 01:19, H. S. Teoh wrote:
On Mon, Dec 10, 2012 at 06:41:25PM -0500, Andrei Alexandrescu wrote:
Hello all,
Walter and I have had a long discussion following his trip to
Australia. Following the current sprint for Win64 (which we all, I
think, agree was long overdue and had to be done), the main area we
need to work on (as I'm sure many would agree) is improving our
process, in particular the approach to releasing the compiler and
standard library.
*applause* It's about time we did this right.
Walter has delegated me to lead this effort, and agreed to obey with
whatever process comes forward as long as it's reasonably clear and
simple.
Good to know.
In turn, I'll be collecting thoughts and opinions in this thread,
distilled from previous discussions. We should develop a few simple
git scripts (such as git-start-new-feature or git-start-bugfix etc)
supported by an equally simple piece of documentation describing how
to start a new release, fix a bug, experiment with a new feature,
and such.
Sounds OK to me, though it seems unnecessarily complicated. What's wrong
with just doing things like:
# New feature
git checkout develop # latest dev branch
git branch -b brand_new_feature
# implement said feature
git commit -a
# Merge feature into dev branch
git checkout develop
git merge brand_new_feature
# New release candidate
git checkout develop
git branch -b 2.062-rc1
# prepare code for release
git commit -a
# Release
git checkout master
git merge 2.062-rc1
master must be the development branch. This is a pitfall the Rust guys
walked into: People accidentally send their pull requests to the master
branch instead of the develop branch which overall ends up being a mess
when a reviewer doesn't notice the error before merging.
Otherwise sounds good.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
