Use "strict" git workflow about alignak HOT 23 CLOSED

I think it's too complex.

I think nodoby commit directly, only use PR, a dev check code and check if tests are in the PR, if yes and tests pass, merge the PR in master branch.

So we will have only one branch, the master, and all code in this branch is stable so we can release when we want

from alignak.

I think it's too complex.

It's only another level of branch, and the whole thing can be resumed as this quite simple tree :

  master <--  release-x.y <-- develop <-- fix_or_feature_PR
                      \--- fix_only_PR

from alignak.

Always too complex :p, read my comment ;)

from alignak.

I read it ;) and what you found too complex I found it appropriate actually ;)
that's basically on the line of "Divide and conquer" or "keep things (a little more) separated".

This is to have a crystal clear distinction between merged commits/PR which have passed the tests (develop and/or release branches) and actually really released (normally stable) version (master branch)..

see it ?

from alignak.

There are advantages to using a develop branch.

For example: when a bug is found in the latest release, it is fixed in the master banch (not develop). Then it is released again. It makes more sense to rebase develop on master than merge a patch in develop. New features should be built on top of what is released.

from alignak.

See you sat master 'normally released'...
We will have too many branches and I thinkit will require more time to manage them

from alignak.

We will have too many branches and I thinkit will require more time to manage them

I don't really understand the complexity of managing branches. Organized work should be less complex than unorganized work.

from alignak.

For develop and master branch I'm now agree with you ;)

But not sur have xx branches because after all people not know on what branch make the pr

from alignak.

Whatever the final decision ... I think that this decision should be written down in a "How to contribute" file in the root directory, with clear examples. It should avoid wrong usage of the process for not regular contributors

Best should be to open a page in the project Wiki ?

from alignak.

But not sur have xx branches because after all people not know on what branch make the pr

we will kindly remind them if they would choose the bad one to merge against ;)

from alignak.

Don't forget too one release = one tag, so we can return on a tag if required ;)

from alignak.

mohierf a file on root and a page on the doc in readthedoc site

from alignak.

@ddurieux : yes ... but if the rules are different than the one described on readthedoc ?

from alignak.

Alugnak readthedo not yet created but very soon ;)

from alignak.

Should we agree on this for the next release:

  master <--  release-x.y <-- develop <-- fix_or_feature_PR
                      \--- fix_only_PR

From: http://nvie.com/posts/a-successful-git-branching-model/ (really worth reading !)

from alignak.

Having a specific release branch for backport can be good but I am not sure about your scheme here. You would like to merge into develop then into release and then into master?

from alignak.

Each fix or feature is made in a dedicated branch.
This branch is first merged to develop that is used to integrate all fixes and features.
When we want to release, we create a release branch from develop to make a RC version
For fixing bugs found in the RC, we create a fix branch that will be merged to the release branch
When the version is stable enough, we merge release to master

This process is clean and simple enough

from alignak.

I don't see the difference between develop and release then. If we want to only merge fixes in develop it is up to the team (Freezing time). Feature branch will always exist even if not merged right?

The fact you think we may need a release branch may indicate that you don't feel safe enough in develop. Is is correct?

from alignak.

The main interest in the release branch is to have a still version of the repo while the develop branch mau contain fixes and features not yet released.

Let's say we release a 1.0-RC1 version and we have many issues. We will be able to fix the issues gently in the develop branch and keep this RC1 version untouched until we find develop enough stable to release a RC2.

Furthermore, it is not a constraint to have this branch ...

from alignak.

I don't see really the advantage of creating a branch for every release. Release are made by tag on a branch, not by creating a branch itself in my opinion. You still can have RC1/2/3 on the master branch. People that are willing to take only stable stuff will only pick non-rc TAG right?

I don't see what is the point of master on what you suggest. I also do see what are the limitation of the current model.

Having a branch for a specific release so that we can backport patch is fine however.

from alignak.

It is your last sentence that makes me prefer having a release branch 😉

from alignak.

My last sentence explains why it can be an exception for a long term support, not a required branch in the development process.

from alignak.

A branch for release is good to manage the fix versions, so

• develop = current dev (no next major version)
• release = the major x.x version where we will tag x.x.x, x.x.y ... (so fixed /minor versions)

from alignak.