So I thought a little about our branching system and how it is generally done in git.
I do not have much expertise in managing branches, but I read a few articles and know how it is being done, where I work. So I set my ideas up for discussion here, until we finally decide on how to do it.

Starting with the 0.9 builds, we had two major versions of Logistics Pipes and we kind of always had it that way. There are the more stable builds in 0.8, where we do not commit any new features that may break the game and there is the version 0.9, where we added quite a lot of features (kudos to every contributor). Both branches receive bugfixes, which is important of course.
There are a few other branches that are mainly being used for experimental features or feature sets.

Now to what we actually want to have in terms of a branching system.
Right now there are three branches that are connected to Jenkins CI, which are mc17, mc17-0.9 and mc17-0.9-bc7 (although that one is not visible on Jenkins yet). And it makes sense to continue using Jenkins as we always did: Have a project with the version number that is being built from the sources.

So why changing something, if everything sounds so perfect? Well, there are no "constants" in this system. Moving to a new version always means moving to a new branch name, which changes quite a bit and is not common in the git environment. Our base is two branches, where one contains stable sources and the most recent one, which contains new features and also gets feature-branches merged into. Thinking of our system this way and making those branches a "constant", I would use the (usual git) name master as the primary branch and that should also the the default branch, when you look at our project on GitHub (this is for everyone seeing the activity of the project and also serves stats & SEO). A fitting name for the second branch containing the stable sources and our stable version could be stable (as fitting as it sounds). Now every time we release a new version and make the feature version a stable version, we simply have to hold our automatic Jenkins builds, merge master into stable, then adjust the Jenkins projects, push a new version to master and create a new Jenkins build job for that version.
In the end this is a logical process and not as chaotic as it was before. Also it is much easier for anyone new to the project to see which branch he wants to look into and maybe make a pull request.

But ain't I missing something important here? Well, two branches sounds so easy, but what if a new BuildCraft version comes out and we want to support old and new at the same time? Or ultimately what if we finally want to move to MC 1.9 (if that is better than 1.8)? But this is simple to answer: Any change that needs to co-exist (as in having a special job for new builds on Jenkins) will be merged into the origin at some point, so it will have it's own branch. I think that is better explained in an example: Moving to 0.9 as our stable version we will have two branches for 0.9: stable (Minecraft 1.7, BuildCraft 6.4.*) and stable-bc7 (Minecraft 1.7, BuildCraft 7) and at least one branch for 0.10: master (Minecraft 1.7, BuildCraft 7). In the future there may be master-mc19 or even master-mc19-bc7.1 or similar branches. This of course means that a version switch is a bit more than just merging master into stable, but it gives everyone a better overview and better control for us. We can decide at any point to drop bugfix support for older BuildCraft versions (because no-one is using that BC version anymore, or we cannot provide that version with fixes anymore) and then merge the according branch into the origin (e.g. master-mc19-bc7.2 --> master-mc19).

The most important change will be (as long as everyone keeps developing with the rules in mind) that we stop having a mix of builds with incompatible BuildCraft (maybe other mods as well) versions. For every new incompatibility there should be a new branch and a new Jenkins job. When you download the mod on Jenkins you can then see for which BuildCraft version it applies, directly. Also you can directly see by deactivated jobs, where we dropped support. And if we make a bugfix, we can merge that fix across all branches and have a new build for every supported BuildCraft version.

Now that's the idea. I hope I have every situation covered by it. If I am missing something, please say so in the comments. Questions are welcome, too.

@davboecki because I have talked little about this with you, can you give me an honest feedback as well?

done.

I agree with you in most points. Only the name choice is a little bit of a talking point. But before we do this we should finish our code style cleanup.

@theZorro266

If I can say anything from an user aspect, I absolute love this idea but only if the current style of job names will not change, so I can quickly decide from Jenkins project listing page which version I need without needing to check the description of the job. But, this is my very private opinion, I accept if you simply ignore this.

@hron84 it is supposed to stay as easy as it is right now. When new versions come up, the deprecated ones will have that grey dot, as the jobs have in the archive.

Supercool, I like it.