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 Seems to me these are all straightforward everyday git commands. The whole selling point of git is that branching/merging is so easy that you could do it multiple times a day within a single implementation effort. For example, I frequently find myself doing things like this: # I want to implement feature X today git checkout master # Implementation attempt #1 git checkout -b feature_X_1 vim feature.d # code code code # While coding feature.d, I got inspired by an idea of an # alternative implementation. So, put current code aside and # test idea on new branch. git commit -a git checkout -b feature_X_alt_impl vim feature.d # implement alternative approach # Turns out, alternate approach doesn't work. Go back to # original approach. (But leave alt_impl in case I decide later # to go back to it.) git checkout feature_X_1 vim feature.d # more code # I hit a difficult spot in the code. Put it aside and work on # other stuff first. git commit -a git checkout master vim main.d # do some routine maintenance, bugfixes, etc. git commit -a # Take afternoon nap. While resting I got another idea for # feature X. git checkout feature_X_1 vim feature.d # try out new idea # Turns out, it needs a big change. So don't commit to # feature_X_1, but use a separate branch. git checkout -b feature_X_new_idea vim feature.d # more code git commit -a # I decide that feature_X_new_idea is the way to go. So fold # into feature X branch. git checkout -b feature_X_1 git merge feature_X_new_idea # I don't need the new idea branch anymore now that it's been # adopted as the "official" way to implement X. Also, the # previous alternative approach was a dead-end, so junk that as # well. git branch -d feature_X_new_idea git branch -d feature_X_alt_impl # Continue working on X vim feature.d git commit -a # I decide that it's now stable enough to merge into the # mainline code. git checkout master git merge feature_X_1 This can happen several times a day when I'm doing a lot of coding. > (One piece that has been brought forward is > http://nvie.com/posts/a-successful-git-branching-model/ - something > to keep in mind.) [...] Glanced at it briefly. I think the basic ideas behind it are sound. Whether or not we should adopt all of the specifics is up for discussion, but I think we should definitely incorporate the main ideas: (1) have a release-ready branch, (2) a separate dev branch, and (3) always use a separate branch for new features so that if things go wrong or it takes too long to finish implementation, development work on other stuff can continue without being held up by bugs in the new feature. Furthermore, in a git environment it's perfectly normal to have multiple "exploratory" or "sub-feature" branches within a single feature branch, like I illustrated above in exploring how to implement feature X. These are usually just local branches, but if the feature is complex enough, it can warrant pushing to github so that other devs can also play around with the alternative implementation approaches. Eventually the best approach can be merged back to the feature branch and the others discarded. Personally, I find that this approach is very profitable, because you don't have to worry that a particular breaking change may turn out to be a dead-end; do the experiment in a sub-branch and throw it away if it doesn't work. The cheapness of doing this allows one to explore ambitious or risky approaches without affecting the stable "traditional" implementation, and so opens up the possibility of discovering new and novel ways of doing things that are usually left unexplored. T -- It said to install Windows 2000 or better, so I installed Linux instead.