GIT flow

[Alexander Broekhuis <a....@gmail.com>]

Hi all,

With the transition to GIT I think it is also time to discuss how we are
going to use it. In the GIT discuss thread I mentioned GIT-flow, and I
still think it makes sense to use it as describe on [1].
This means:

* Do work on a local feature branch, ideally identified by a issue number.
This also makes sure we have an actual issue to track.
* If needed, this local branch can be pushed, for example when people need
to collaborate on that specific feature.
* When a feature is done, merge it into the develop branch. NOTE: THIS IS
DIFFERENT THEN BEFORE! So we do not push directly to master, only to
develop.
* When preparing a release, a release branch is created.
* If the release is done, changing from that branch are merged back to
develop, but also to master. This means that changes made on the release
branche are merged back to develop, so development can continue. But the
merge to master means that master always stays stable.
* [1] also mentions hotfixes, and while they are important, I think we
should always make a release if a hotfix is needed.

So the following branches play a role:

* master: Branch on which the latest release can be found
* develop: Branch on which development is done
* feature/CELIX-###_description: Branch on which a new
feature/bug/patch/... is implemented
* release/v#.#.#: Branch on which a release is done, this includes
packaging, touching up headers and other files etc.
* hotfix/CELIX-###_description: Branch on which a hotfix is made, which
will be based on master. A hotfix (or multiple hotfixes) should result in a
new release.

I'm now using SourceTree, and it has support for gitflow as described above.

As I said, this is how git-flow is described. If there is a (good) reason
to do things differently please reply to this mail!


[1]: http://danielkummer.github.io/git-flow-cheatsheet/

-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: GIT flow

[Pepijn Noltes <pe...@gmail.com>]

On Fri, Mar 27, 2015 at 6:13 PM, Alexander Broekhuis
<a....@gmail.com> wrote:
> 2015-03-27 16:28 GMT+01:00 Marcel Offermans <ma...@luminis.nl>:
>
>> On 27 Mar 2015 at 12:46:01, Alexander Broekhuis (a.broekhuis@gmail.com)
>> wrote:
>>
>> This means:
>>
>> * release/v#.#.#: Branch on which a release is done, this includes
>> packaging, touching up headers and other files etc.
>>
>> This implies:
>>
>> 1) We only release “everything at once”.
>>
>
> For the time being I think that will be the case. With the current cmake
> solution it is not easy to release only one part. Also even if we want to
> do a release of one component, I think the tag/branch is on the repository
> level (I doubt we will make any binaries available as part of the project
> for any of the next releases).
> If so, in that case the version tag/name could be a bit more extensive, eg,
> release/dependency_manager-1.0.0 etc.

+1 for the git-flow and +1 for the release "everything at once". When
there is a need for separate releases, we  discuss then.


>
>
>> 2) #.#.# sounds like we use some kind of semantic versioning for the
>> releases?
>>
>> I am not disagreeing with either, just making sure my conclusions are
>> correct.
>>
> I would like to use semantic versioning. But I'm not sure if it should be
> applicable to the top level (overall) version number. Within the project
> the separate bundles do have an own version as well. For those semantic
> versioning makes more sense.
>
> I think versioning as well as releasing all as one etc needs more
> discussion when we are ready to make a next release. I hope this can be
> done rather sooner than later. Personally I'd like to make a new release
> once APR has been removed completely.
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis

Re: GIT flow

[Alexander Broekhuis <a....@gmail.com>]

2015-03-27 16:28 GMT+01:00 Marcel Offermans <ma...@luminis.nl>:

> On 27 Mar 2015 at 12:46:01, Alexander Broekhuis (a.broekhuis@gmail.com)
> wrote:
>
> This means:
>
> * release/v#.#.#: Branch on which a release is done, this includes
> packaging, touching up headers and other files etc.
>
> This implies:
>
> 1) We only release “everything at once”.
>

For the time being I think that will be the case. With the current cmake
solution it is not easy to release only one part. Also even if we want to
do a release of one component, I think the tag/branch is on the repository
level (I doubt we will make any binaries available as part of the project
for any of the next releases).
If so, in that case the version tag/name could be a bit more extensive, eg,
release/dependency_manager-1.0.0 etc.


> 2) #.#.# sounds like we use some kind of semantic versioning for the
> releases?
>
> I am not disagreeing with either, just making sure my conclusions are
> correct.
>
I would like to use semantic versioning. But I'm not sure if it should be
applicable to the top level (overall) version number. Within the project
the separate bundles do have an own version as well. For those semantic
versioning makes more sense.

I think versioning as well as releasing all as one etc needs more
discussion when we are ready to make a next release. I hope this can be
done rather sooner than later. Personally I'd like to make a new release
once APR has been removed completely.

-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: GIT flow

[Marcel Offermans <ma...@luminis.nl>]

On 27 Mar 2015 at 12:46:01, Alexander Broekhuis (a.broekhuis@gmail.com) wrote:

With the transition to GIT I think it is also time to discuss how we are 
going to use it. In the GIT discuss thread I mentioned GIT-flow, and I 
still think it makes sense to use it as describe on [1]. 
+1

This means: 

* release/v#.#.#: Branch on which a release is done, this includes 
packaging, touching up headers and other files etc. 
This implies:

1) We only release “everything at once”.

2) #.#.# sounds like we use some kind of semantic versioning for the releases?

I am not disagreeing with either, just making sure my conclusions are correct.

Greetings, Marcel