search

CasparCG / server

CasparCG Server is a Windows and Linux software used to play out professional graphics, audio and video to multiple outputs. It has been in 24/7 broadcast production since 2006. Ready-to-use downloads are available under the Releases tab https://casparcg.com.
GNU General Public License v3.0
913 stars 268 forks source link

Rename branch 2.2.0 to master #858

Closed dotarmin closed 6 years ago

dotarmin commented 6 years ago

Hi!

I have been thinking a lot about the naming convention for existing branches and I think that we should rename branch 2.2.0 to master once for all and have the master to be the one where all development is occurring.

But wait... If future development is going to happen in the master branch, where will stable reside? Well, when we feel that the development of the master branch is in a point of time where we feel we can release it either as alpha, beta or stable then we should tag it instead and continue development against master.

Builds... By going this approach we can simply have builds for tags (and master of course) and also be able to patch older versions if needed when needed.

The reason I'm creating this issue is a question of workflow, do we wanna stick to the branching off flow for each version? @ronag I know why you did a 2.2.0 branch so this issue is not related to that at all (just so you know 😄), I just feel it's time to have a nice workflow with the code, make it easier to contribute and have a clear builds.

Any thoughts?

TomKaltz commented 6 years ago

I recommend we do something like git flow

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Julusian commented 6 years ago

I recommend we do something like git flow

I have been thinking about this too, but hadn't gotten around to opening an issue for it yet. I agree that git-flow is a nice way to do branches.

ronag commented 6 years ago

Why? You don't like my git rambo?

ronag commented 6 years ago

Jokes aside...

We rename 2.2.0 to master and then create a 2.2.x branch? I think the way Node does it is both simple and makes sense.

TomKaltz commented 6 years ago

It would be nice to have something like git-flow but a simple master -> next branching system seems sensible enough for this project since there aren't many developers. So you're going to branch the current master as ??? and then rename 2.2.0 to master?

Julusian commented 6 years ago

I think that using versioned branches would be better, but it really depends on whether SVT/maintainer intends to follow semver properly.

We rename 2.2.0 to master and then create a 2.2.x branch?

Make sure to rename master to 2.0.x first :)

TomKaltz commented 6 years ago

Won't renaming close PR's? I mean I guess it could be a way to clear stale PRs before a release although not sure if it's very friendly to contributors.

Julusian commented 6 years ago

Probably. Does github even support renaming a branch? It will only matter now though (and affect one pr currently in the next milestone) , as in future it should get branched before a release rather than renamed.

dotarmin commented 6 years ago

@TomKaltz I recommend we do something like git flow https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

I have been playing around with various workflows for git in a couple of years and I have to say even if those all have their pros and cons I have to say that for a project like this (seen to the number of developers) it could easily give the project an overhead, even if some of the workflows are well tested and works. CasparCG Client uses the principles of this git workflow you're referencing to but not exactly like that.

Why? You don't like my git rambo?

@ronag We love your Rambo stuff! 😄

I think we should rename current branches as following:

master => v2.0.7 _(and create another branch from this (if it builds) and name it v2.0.7-release) 2.1.0 => archived-v2.1.0?? 2.2.0 => v2.2.x

As @ronag stated, node have a nice and easy workflow, the use a dev branch for each major version (v.2.x) and then they have a staging branch with cherry picks (v.2.x-staging) and finally a branch for each release (v.2.2.0-release), that is later on tagged as well.

I have been working on contribution guidelines but this is something that I could manage write down quickly and upload it to GitHub, a git workflow for the project.

ronag commented 6 years ago

Done. This will fuck up a bit for people with local clones. But they'll have to live with it this last time :).

dotarmin commented 6 years ago

Done. This will fuck up a bit for people with local clones. But they'll have to live with it this last time :).

It will be worth in the long term for the project! Good job and thanks!