Use gitflow to organize contributions and separate develop from releases

[julian-alarcon]

Hi @IsmaelMartinez @benyanke

I'm checking the current flow and I think that it's better to use a develop branch where things can break, and focus on getting releases branches when we think that a new release is needed (bug fixes, new features, etc).
So the idea will be:
All most all commits on develop -> Release branch e.g. 0.2 release.
When release is done tag it and then merge to master (so master will always have the latest stable release, every commit on master is a new release by definition).

If someone want to contribute, or even us (feature/bugfix), the branch to use will be develop always.

I more detailed explanation can be found here: https://nvie.com/posts/a-successful-git-branching-model/

I already created the develop branch from master, what do you think about this?

[julian-alarcon]

BTW I uploaded a new version to snapcraft.

julian@pc:~/Code/teams-for-linux/dist$ snapcraft status teams-for-linux
Track    Arch    Channel    Version    Revision
latest   amd64   stable     -          -
                 candidate  -          -
                 beta       0.1.17     2
                 edge       0.1.18     3

The idea, to me, is that edge will always point to develop branch, stable will always point to latest stable (right now 0.1.7) release, as master will always be the latest stable release snap build should point to that branch. Beta could be used for releases marked as draft. Candidate is not needed for us right now.

So, stable and edge are the main channels, beta just when we needed them.

All this is related to snap store, for AUR on Arch Linux, they should always point to master @frealgagu
https://aur.archlinux.org/packages/teams-for-linux/

[IsmaelMartinez]

Hi @julian-alarcon ,

I like the idea, as long as we know that 0.1.18 might never be released (as it will become 0.2.0)

For arch, and as you have added @frealgagu in here, it might be great if we can sync with them in terms to know what they want/need. We could do their build process if that accelerates and eases the managements, or we can ping them when a new master release is ready.

Thanks @julian-alarcon!

[IsmaelMartinez]

Just to keep tags with the current format, we should probably use v0.2.0 (with the v in front and 3 levels)

TODO:

• create develop branch.
• default develop branch in github
• create CONTRIBUTE.md with the guidelines to contribute (current)
• document this in the CONTRIBUTE.md

I see if I can do some of this before release v0.2.0. Can you @julian-alarcon , do some of this?

I will try to do the point 1,2 and 3 now. I got a bit of time (10 minutes)

[IsmaelMartinez]

By the way, I don't think we need a "release branch", we are not a lot of people developing at the same time. As long as a new tag is created that should be ok.

[IsmaelMartinez]

Hi @julian-alarcon ,

Looks like a tag is automatically created by github when creating the release notes.

Basically,

• develop is the default branch where any pull requests and new development goes.
• master is the release branch where only stable things goes.

When creating the release notes, a tag is created with the version (this is automatic).

• develop points to edge in snapcraft
• master points to stable in snapcraft and any other releases (including arch)

The only "issue" with the snapcraft, that might be ok, is that some edge releases numbers will never be actually release.

I don't think we need further details in the contribute page, so closing this. Do feel free to update the contribute with further info if you consider it.