Prod branch

[robcarver17]

Picking up on comments in #1063 should we have a production branch?

Or should we treat master = stable production, which has the advantage that a naive user will always pick up a stable version, and have a seperate develop branch which is then merged into master when stable?

Relevant material: here and here

Note the develop branch is (usually) effectively the 'feature branch' for the update I'm currently working on. The advantage, for me, of a single develop branch is that I will usually be running my own trading server off that branch, so I don't need to keep switching to a new feature branch every time I work on something new.

Sometimes I will want to use a new feature branch for something I'm testing locally but not (yet?) testing on my server; that will branch off develop.

Other users may also have feature branches that branch off develop depending on the situation.

I wouldn't allow direct merging of feature braches into master, only into develop.

[tgibson11]

I agree with Rob that master should always be stable, and I like the GitHub Flow process described in the first link.

That process (GitHub Flow) is essentially what contributors are doing now, with the feature branches being in their own forks.

I see no reason for that to change, unless we expect to have multiple contributors collaborating on a feature. Even then, that could just as easily be done in someone else's fork.

The only real change here would be that Rob would work on features in another branch (what you call it is irrelevant), and only commit/merge to master when he considers something ready for general use.

[bug-or-feature]

Any improvements to the current (non) process would be most welcome. Is there enough discipline to do it properly though?!

[robcarver17]

Hahah good point about the new years resolution... but with a single develop branch it's a lot less work and actually seamless now it's set up: I've written a short bash script to merge develop into master and switch back to develop afterwards; the rest of the time I'm working on develop, and switched my production machine permanently to develop.

[robcarver17]

OK 'tis done. I've created a develop branch, and hopefully the master will now be relatively stable.

[VMatthijs]

For what it's worth, this makes a lot of sense to me! Most projects I have worked on do it in this way and it's always been quite satisfactory.

[tgibson11]

Do you want new pull requests to go into the develop branch?

[robcarver17]

Yes I think that makes most sense

[emretezel]

Hi Everyone,

I was one of the proponents of having a prod branch (i.e. our current master branch), but with hindsight I am having second thoughts on whether this is the best practice.

I now believe having a single main branch that is most of the time stable and has all the latest features (what we had before) was the better approach. In this practice, one should however develop significant changes first in feature specific branches and merge them into master when they are complete (for example parquet changes). It would also be good practice to use tags on the main branch to identify stable points in time and for versioning. Small fixes could be developed directly in the main branch.

This is only some food for thought, it would be nice to 1) fully merge develop into master, 2) delete develop branch, 3) develop large changes in project specific branches and merge into master when complete and 4) use tags more often on master branch.

The project specific development branches don't even need be pushed to github unless multiple people need to work on one.

Best,
Emre