ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Git branches and development process.
Date Sat, 06 Jun 2015 20:17:32 GMT
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.


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 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
>>
>
>

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