Make clear branches.

[jklmnn]

We currently have a lot of different branches on different states. I recommend to use some rules to get these branches under control:

• the current stable release is always on master
• changes on master only contain bugfixes
• the next stable version is always on experimental
• on a major upgrade experimental is merged in master
• new functionalities or APIs that are not bugfixes must only be forked from and merged into experimental
• bugfixes that have been applied to master also have to be applied to experimental unless the bug is fixed/not existent anymore through another change
• equal branches have to be merged together
• branches that cannot be merged anymore either have to be recreated or deleted

The reason is, that we have currently two branches that address a new version and that some changes that made it into master have not be applied to either of these two so these bug might be again in the next version.

[J-8]

I wholeheartedly agree. Good idea and structure. That would fix the current confusion. Can you put those rules in the wiki or somewhere? Really good thinking there!

[jklmnn]

I'll write a wiki entry.

[jklmnn]

@J-8 @beli3ver please review the branching guidelines. If you think they are ok, I'll restructure the project according to these guidelines. I would fork devel from master and try to merge experimental into devel, because experimental cannot be automatically merged at the time.

[ghost]

Good idea, I am in :lollipop:

[jklmnn]

I have now (after checking) deleted all branches except master (2 pr-branches that were ~100 commits behind master; PDO because it was forked from the old master and not anymore mergable, I will look if I can transform all database connectors to pdo; and the experimental branch since it was even with master). I also have created the devel branch from master. This will be the next version.