On Thu, Feb 17, 2011 at 4:48 AM, Michael Pedersen <[email protected]> wrote: > On Wed, Feb 16, 2011 at 6:50 AM, Alessandro Molina > <[email protected]> wrote: >> >> Stable code related to the "in development version" or "code of stable >> releases"? >> As I think that it is usually better to have development code on >> master and stable releases on their own branches as it makes easier to >> release patches and fixes for that specific release. > > Well, what I'm reading makes me think that the common/accepted practice for > git is to have the master branch be the "nothing happens here" branch. > Basically, whenever a development cycle is closed, the tag gets applied, > everything gets migrated to master, and the development branch picks up new > topic branches from there. This seems to have an advantage that all code > (security fixes, especially) will eventually find its way to the master > HEAD, or it's not fully integrated, and there's no question about it. Having > a branch for all 2.1 code would allow a security fix to be applied only to > 2.1, and never applied to master, and that would be (almost guaranteed) > wrong. > > I'm open to hearing why my understanding is wrong, though. I'm not a git > master, and am willing to be shown a better path. >
Indeed it is the most common behavior among git users, but I find that it makes harder to maintain the previous releases. Let me make an example: Suppose you have just released 2.1 and you are now working on 2.2, you think that the 2.2 is stable and merge back your development branch in the master. In the mean time you discover that there is a huge bug on 2.1 and you really need to release a 2.1.1, how do you plan to do that without also realeasing the just merged in changes of the 2.2? While using a branch for each stable release has the disadvantage of having to pay attention to pushing a bugfix to each version where it is important it makes easier to maintain the previous releases. I can provide as an example a project that I maintain and that uses git: http://cgit.lscube.org/cgit.cgi/flux/ As you can see it has all the stable releases both tagged and branched (1.0 and 1.1), "experimental changes" on their own branch (pseudostream and test-autotools) while the development next release preparation branch is the master. I just found myself most comfortable with this structure for previous versions management. The only disadvantage that it has is that users might tend to clone the unstable branch if you don't specifically provide the clone urls of the current stable branch. I'm really interested in a comparison of the two branching policies as it is indeed useful also for my own projects to understand which is the best one :D -- You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
