ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: Git branches and development process.
Date Sun, 07 Jun 2015 06:35:59 GMT
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 <vozerov@gridgain.com>
> 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 <ptupitsyn@gridgain.com>
>> 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 <cos@apache.org>
>>> 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 <ashutak@gridgain.com>
>>>> 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
>>>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message