[Gambas-devel] Fwd: Re: Gambas to Git(Lab)

[Adrien Prokopowicz]

Le Sun, 23 Jul 2017 12:02:30 +0200, Christof Thalhofer  
<chrisml at ...757...> a écrit:

> Here is a good explanation of common git workflows:
> https://www.atlassian.com/git/tutorials/comparing-workflows
>
> Why do you want to develop in different versions at the same time, to
> fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
> what you wanted to do?
>
> I am unsure what sort of development workflow would be the best for  
> Gambas.
>
> If I look at a big projekt for example that put its codebase to Git –
> OTRS – they did it so:
>
> https://github.com/OTRS/otrs
>
> Look there at the branches and tags. They seem to have ongoing
> development in master with branches for the "big" releases. Tags are
> used to point to subreleases.
>
>
> Alles Gute
>
> Christof Thalhofer

I took a bit of time to think about it, and I think the best workflow for
developing Gambas would be the one that's described in the Git  
documentation[0] :

- The master branch is the stable branch : it only contains the latest  
stable
   release of gambas. (with tags to keep the previous releases).
- A dev branch, for the development version. (the equivalent of the  
current trunk).
- Various branches for work-in-progress features that are not ready at all  
(like gb.term.form)

This way, we keep a workflow similar to the current one for bug fixes &  
minor changes
(we just commit to the dev branch).
For bigger changes and experimental components we create a new branch from  
the dev branch,
work on it, and then merge it back in the development branch when it's  
ready.
And when we want to release a new Gambas version, we just merge the  
development branch
in master, and create a tag to mark the new release.

If we need to make a patch release for bugfixes in the meantime, we can  
just use the master
branch to get back to the latest stable, and then make the fixes from  
there.
If the fix is already done on the development version, we can cherry-pick  
it from the dev
branch, and otherwise we can just make the fix on master (or on a  
temporary branch), and
then merge master back into the development branch.

This is also the workflow I use at work so maybe I'm too used to it and  
don't see
the downsides, but to me it seems to cover all of the use-cases.

[0] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

-- 
Adrien Prokopowicz