Horde3D

I was wondering should all should all modifications, patches, fixes etc go to develop -branch first, and then someday they maybe goes to master branch?
Because in github, it shows in develop branch that "This branch is 60 commits ahead and 31 commits behind master", I understand that "60 commits ahead", but don't understand why develop is behind master?

A good question. I thought that develop branch is for experiments and master is for current stable, but I have to admit, that I haven't used two branches in any VCS so far, so maybe my way to commit fixes for both branches is not the one normally intended by git.

I havent used git (much) and dont know which is right or wrong but I think (and it would be nice) that develop is at least what is in master (so if git pull develop, there is master+develop patches and can put code on them

Hello, long time no post I've been always lurking in the shadows though

I've seen that some projects use "master" for the current release in bug-fix only mode and have some sort of "next" branch for the upcoming release. In addition to that they have extra branches for feature development or experiments. These merge into "next" and "next" merges into "master". This way "master" is always stable and feature development is kept organised.

Maybe we could do the same?

_________________
Paul

"and master is for current stable"

So these fixes should be in develop too.

Therefor more like this?

"master" = current stable + fixes
"next" = current stable + fixes + mature new features
"next-feature-x" = current stable + fixes + experimental feature x

And merging hierarchy:

"next-feature-x" -> "next" -> "master"

_________________
Paul

I think thats a good idea.
And maybe attila's OpenGLES2 and D3D11 port to official repos too so merging to official is easier. At least OpenGLES2 works fine, have tested it with my phone.

Yes, adding those would fit nicely the scheme. We could have "next-opengles2" and "next-d3d11"

One thing I am not sure is how bug-fixing multiple branches is handled. Work on "master" and commit to all?

_________________
Paul

It might be the best, but Im so unfamiliar with git yet, cant say how easy it is to all ...

If one uses branch-xxyy and found bug, and send fix, it goes to it, then Volker must download that patch and apply to master? Dont know is it easy or even how to do it.

Or if send patch-file which goes straight to master and then update all branches..this idea still isnt the best.

Anyway, hopefully there will not be braches that some has fixes and others doesnt, it means git isnt used the right way.

Yes. Having fixes in only some of the branches is most undesirable.

Best thing we can do now is look at how big git-using projects handle this. I think the Linux kernel is as big as it can get.
What I was proposing was inspired from how Gameplay3D does things.

_________________
Paul

I dont think size is the matter ever (in github) (at least if everybody can delete projects which doesnt use, I just yesterday removed couple old projects, let hundreds of megabytes each to free).

I meant big regarding the amount of development, the number of patches that needed to be integrated, number of branches.

_________________
Paul

Aah, now got it
(btw, Im just doing h3d+gameplay3d, works great together (im using gp3d node-system, not h3d's one. so I can hopefully integrate its physics soon, all other I have done)

Currently the changes done so far are mostly intendet for both branches. I usually merge the pull requests and the cherry pick the commits in the other branch. Conflict resolving is something that I normally only do under subversion or mercurial. Both have a common naming for all the necessary steps. Git is a bit different in all those steps. So I hope zuck will help keeping the branches consistent in the future. I'm currently a bit limited in spending time on the project.

At the moment, according to the project vision of to be simple, we chose to only have 2 branches on official Git repository:

• master: last stable release + critical fixes
• develop: last stable release + critical fixes (merged from master) + new (almost stable) features

Regarding releases, the idea is that master could generate new releases at any time while develop branch can't never.

Of course, there are currently some issues in this workflow (we have to getting rid of these 31 commits behind master as soon as possible!), but at the moment new feature branches are not in plans.

Why?

Simple: because GitHub is a social development platform, so feature branches are simply all branches from forked repositories of other developers.

The Pull Request mechanism on GitHub works very well, so each new feature could be tracked without adding new (quite/very unstable) branches to official repository and merged back to official repository with just one click.

It also brings the advantage to reduce time and resources to fork the project for a new developer.

I'm also working to provide a contribution guide which should help new developers effectively contribute to Horde3D project without troubles:

http://www.horde3d.org/wiki/index.php5? ... contribute