The diagram you drew below is pretty much what the flow I've referenced to does. On top of it the flow allows to merge a bugfix/feature to multiple branches: development, release, etc.
Another point: cherry-picking in git should be avoided wherever possible as they change commit SHAs and make tracking a way harder. And yes - wholeheartedly agree that VCS model should be as simple as possible. Cos On June 7, 2015 9:35:59 AM GMT+03:00, "Branko Čibej" <[email protected]> wrote: >On 06.06.2015 22:17, Vladimir Ozerov wrote: >> I think I understand why we do not use schemes proposed above. They >are >> definitely better than current. But we cannot use them because of two >> things: >> 1) We do not have real "stabilization" phase. Normally it must >include >> mainly bugfixes, but we usually continue filling development branch >with >> features as much as possible up to the last day before release. So we >> declare it as "stabilization", but in reality nothing changes and >this is >> still active development. >> 2) We do not have good versioning policy - for now it is normal to >change >> versions several times in a sprint. >> >> If we get rid of these two problems, we certainly can employ proposed >> schemes and gain benefits from it. > >The thing to do is to turn the whole structure upside down. Instead of >having several development branches and doing stabilization on each of >them, instead, have /one/ development branch and stabilize the release >branches instead. And call the development branch "master". > > +- feature-X ------+ > / \ > master (development) ----------------------(tag-X)-------- > |\ > | +- rel-1.2.x (stable) -------rel-tag-1.2.0-RC1-------- > \ > +-- rel-1.1.x (stable) --------------rel-tag-1.1.13---- > > >The process is then: > > * All development happens on the "master" branch. You can still create > long-lived feature branches off the master branch, to avoid too much > destabilization: the rule should be that code always compiles and a > certain group of tests (usually called "smoke tests") always pass on > the master branch. > * When you're ready to begin stabilization for a release, create a > release branch (rel-1.2.x for example) from the master branch. Only > bug fixes happen on the release branch. When you're happy with the > stability of the release, just tag the release branch (e.g., 1.2.0) > and publish. This now becomes the bugfix branch for the 1.2.x release. > o Its up to you to decide how you fix bugs on the release branch; > there are basically two ways to do this: > + Fix all bugs on master and cherry-pick them to the release > branch(es). This is the preferred method because it ensures > that all bug fixes are present in all future releases. > + Fix bugs on the release branches and merge them back to > master. This works but > o Since many releases go through a number of release candidates, > you can tag each candidate (e.g., 1.2.13-RC5) on this branch and > have a history of what was fixed between candidates. > o You can easily maintain several releases at the same time. This > becomes very valuable once you've finally defined a version > compatibility policy. > > >This structure is very easy to understand: master is always the >bleeding-edge, release branches are always stable (and contain the >actual release tags), feature branches are mostly irrelevant and >ad-hoc. >There's an additional benefit compared your current model where master >only contains the latest released code: it doesn't really let you >maintain several release streams at the same time, whereas my proposed >model does. > >Also there's a serious flaw in the concept of sprint branches; there >are >two invalid assumptions: > > * The first invalid assumption is that you can shoehorn a particular > development process on every member of an open-source community. > That just doesn't work in practice: open source developers, > especially those at the ASF, usually have other interests in their > life (e.g, the jobs they do so they can eat) and they will loose > focus and go away for a while, etc. > * The second invalid assumption is that you can plan releases by > "sprints". You can do that if all your developers are essentially in > the same room and can talk face-to-face on a daily basis. You cannot > do this if you depend on random contributions from the community. > Consider someone coming in with a patch ... which of the 15 current > sprint branches should it apply to? With a single development > branch, the question doesn't even come up. > > >The main consideration about configuration management workflows is to >keep them as simple as possible. I've often noticed that Git-based >workflows tend to be complex because people instinctively pile on >branches, presumably because branching and merging is so simple. That >approach is not valid. You should always keep the number of public >branches to a minimum that every developer can understand without >keeping a huge SCM manual on her desk. Although you'll find far more >complex workflows in many corporate environments, you'll also find >dedicated teams of "SCM experts" whose only task is to maintain the >various branches and tags and merge stuff to the appropriate one. This >is extremely wasteful (and it also caters to the perceived incompetence >of the average closed-source programmer). You can't afford this kind of >complexity on an open-source project. > >-- Brane > > >> On Sat, Jun 6, 2015 at 11:00 PM, Vladimir Ozerov ><[email protected]> >> wrote: >> >>> I still doesn't understand how does this scheme handle several >>> simultaneous "sprints" (in current terms). >>> >>> Our sprints are usually relatively short (2-4 weeks). On the one >hand, at >>> the end of every sprint we usually have a week or so to stabilize >it. >>> During this time the sprint is not released yet, so it is still >>> "development" branch in your terms. And there is still active >development >>> in this branch incluing bugfixes, finalization of some _almost_ >ready >>> features, critical last-minute-changes etc. On the other hand, at >this time >>> all new major features go to the next "sprint", not to the current, >to >>> avoid regressions. And this is not about a single feature as in the >scheme >>> above. This is about lots of feauters, which usually conflicts with >each >>> other and thus must be constantly accumulated in some other branch. >This is >>> why instead of >>> >>> sprint-5 (development) >>> new-feature-1 (merge to development after release, in a week) >>> new-feature-2 (merge to development after release, in a week) >>> >>> we have >>> >>> sprint-5 (development) >>> sprint-6 (next sprint) >>> new-feature-1 (merge to sprint-6 as soon as ready) >>> new-feature-2 (merge to sprint-6 as soon as ready) >>> >>> I am certainly +1 for using the most common practices, so that >adoption of >>> new people is as easy as possible. But it seems that with proposed >>> solutions we get rid of one problem immediately introducing another. >>> >>> Vladimir. >>> >>> On Sat, Jun 6, 2015 at 8:41 PM, Pavel Tupitsyn ><[email protected]> >>> wrote: >>> >>>> +1 Artiom, Cos >>>> >>>> The link above describes a quite standard approach, familiar to >majority >>>> of >>>> devs, I believe. I have seen it many times before, it works well >for any >>>> VCS. >>>> Current approach with sprint branches is more confusing, and also >requires >>>> changing default branch on TC each sprint. I hear "which is the >default >>>> branch on TC at the moment" quite often. >>>> >>>> Thanks, >>>> >>>> On Sat, Jun 6, 2015 at 2:37 PM, Konstantin Boudnik <[email protected]> >>>> wrote: >>>> >>>>> Actually, this approach works very well for the situation below. >The >>>> way to >>>>> deal with it is explained here >>>>> http://nvie.com/posts/a-successful-git-branching-model/ >>>>> >>>>> And has been discussed on this list a couple of times already. >>>> 'sprint-N' >>>>> branch is not different from a 'development' branch, except that >>>>> 'development' >>>>> is always there, where N is increased all the time in 'sprint-N' >schema. >>>>> That's pretty confusing if you ask me. Another issue with >sprint-branch >>>>> model, >>>>> is that it doesn't support sustaining releases in a transparent >way, >>>>> where's >>>>> the one above (or similarly offered by Artiom) does. >>>>> >>>>> Cos >>>>> >>>>> On Wed, Jun 03, 2015 at 01:51PM, Vladimir Ozerov wrote: >>>>>> This approach doesn't work well when there are several >development >>>>>> branches. E.g. someone is working on tickets for current release, >>>> someone >>>>>> else is working on features for the next release. Current >approach >>>> with >>>>>> "sprint" branches handles this situation. >>>>>> Another problem is that version is subject to frequent changes >and can >>>>> vary >>>>>> for the same set of features depending on some "political" and >>>>> "marketing" >>>>>> reasons. Normally developer should not be aware of versioning. >This is >>>>> why >>>>>> indirection between sprint and version is a good thing. >>>>>> >>>>>> On Wed, Jun 3, 2015 at 1:25 PM, Artiom Shutak ><[email protected]> >>>>> wrote: >>>>>>> Igniters, >>>>>>> >>>>>>> As I remember, the question about hard understandable Ignite >>>> branches >>>>>>> system was discussed many times. But I don't remember the end of >it >>>>> story. >>>>>>> I suggest to have next branches system (nothing new). >>>>>>> >>>>>>> - *development* branch. The branch has the last development >state >>>>> with >>>>>>> all new features. If you start development new feature, you >just >>>>> make >>>>>>> branch from the HEAD of *development* branch and create a >patch >>>>> against >>>>>>> this one. >>>>>>> - *master* branch. The branch has the same state as the last >>>>> released >>>>>>> version of Ignite. As a result, when anyone clone Ignite, he >will >>>>> see >>>>>>> stable version of Ignite and can simply play with him. >>>>>>> - *release-x.x.x* branches. When we think, that development >>>> branch >>>>> has >>>>>>> enough new features for release, we just create new >>>> *release-x.x.x* >>>>>>> branch and make Ignite stable here. After releasing of this >>>> branch, >>>>> we >>>>>>> need >>>>>>> to merge* release-x.x.x *branch at *development* and at >*master* >>>>>>> branches. >>>>>>> >>>>>>> >>>>>>> To get this branches state, we need to >>>>>>> >>>>>>> - "rename" *ignite-sprint-6* to *development* >>>>>>> - "rename" *ignite-sprint-5 *to* release-1.2.0* >>>>>>> - merge last released branch at *master *(if we didn't do it >yet) >>>>>>> >>>>>>> // "rename" = create new branch from the HEAD of old branch and >>>> delete >>>>> old >>>>>>> branch. >>>>>>> >>>>>>> I think this schema will be more clear for contributors, >commiters >>>> and >>>>>>> simple users. >>>>>>> >>>>>>> Thoughts? Objections? >>>>>>> >>>>>>> -- Artem -- >>>>>>> >>>> >>>> >>>> -- >>>> -- >>>> Pavel Tupitsyn >>>> GridGain Systems, Inc. >>>> www.gridgain.com >>>> >>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
