(I should probably post it to soci-devel and avoid development-only noise here, but as it's started on soci-users, let's keep it here)
On 16 November 2012 13:56, Mateusz Loskot <[email protected]> wrote: > On 16 November 2012 13:25, Vadim Zeitlin <[email protected]> wrote: >> On Fri, 16 Nov 2012 12:57:23 +0000 Mateusz Loskot <[email protected]> wrote: >> >> ML> I'm thinking about structuring SOCI development and following >> ML> some well-known GitHub practices regarding branching, tagging, etc. >> ML> >> ML> I've proposed some ideas as a task here: >> ML> >> ML> https://github.com/SOCI/soci/issues/18 >> ML> >> ML> I'd like to ask everyone for comments,especially related to the model >> ML> outlined in the article linked in the ticket. >> >> Hello, >> >> This is not a bad model but I wonder if people are not going to be >> confused by the need to make patches to (or make pull requests for) the >> "development" branch instead of the usual "master". > > I do have exactly the same concern. > I'm not used to the use of "develop" or "next" branch, > but I have seen projects using it (e.g. CMake, i3wm.org). After some more reading and reflection, I think I understand why git-flow uses 'develop' as the current development line and 'master' branch as the stable. I have updated the ticket with the two flows referred https://github.com/SOCI/soci/issues/18 I have learned about git-flow, then I have learned about GitHub flow http://scottchacon.com/2011/08/31/github-flow.html which is also recommended by GitHub in their help documentation. What these two flows have in common is this: "Anything in the master branch is deployable" In GitHub flow, it is "constantly" deployable. In git-flow, it is deployable because 'master' reflects current *stable* snapshot (not necessarily released though). In introduction to the GitHub flow, Scott also points out that merging topic/feature branches off of 'develop' is confusing for many people. In conclusion, he compares these two flows this way: """ For teams that have to do formal releases on a longer term interval, and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use. For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow. """ Obviously, SOCI belongs to the first category and I doubt we would benefit form the GitHub Flow in long term, as it simply does not fit the model based on subsequent release points, with optional look back for hotfix-and-release cycles. I'd like to try the git-flow model. In fact, for most/all of us it will hardly change anything and we still will continue to branch off of one branch (current development), create topic branches, merge back to the branch from which topic branch was created. The git-flow will only affect release manager (currently, it's me). So, I'm fairly confident that adoption of git-flow won't be a PITA. It's not a problem to rename the git-flow's branches * 'master' is the current development line, corresponds to git-flow's 'develop' * 'release' is the current stable (deployable, production-ready) branch, corresponds to git-flow's 'master' Pros: 'master' does not change its default role Cons: git-flow toolset will work with different naming convention, but may be confusing There may be more disadvantages, but I don't see them now. I don't know if I will start using git-flow toolsets myself, I'm more interested in using well-known workflow. Let's go visual. Here is very good illustration of the git-flow timeline: http://danielkummer.github.com/git-flow-cheatsheet/ If we decide to rename the original git-flow branches, then it will look this way: * master - dark blue line, current development work * release - light blue line, reserved for release tags only * release/v.X.Y.Z - orange line, release integration branch If git-flow tools are used, the configuration would be: $ git config gitflow.branch.master release $ git config gitflow.branch.develop master Any objections to go for git-flow? Shall we rename the branches as above? Why the flow really matters to me? - ***no-brainer*** interaction with Git (I really don't want to think hard during every release, I just want to automate it) - enable release early, release often - previous releases easily accessible - even if we don't plan hotfixes now, we will be ready to issue them when it's needed - multi-version documentation easily managed - easy way to compare what has changed between releases - if project/release manager changes, well-known flow will play key role on switch Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
