Manage branches

[CapacitorSet]

As per discussions:

• Compare master and dev, merge the latter into the former (edit: this is no longer relevant, as master was outright deleted)
• Delete dev

[blackdev1l]

I'd suggest to learn (and use) a branching model such as git flow
http://nvie.com/posts/a-successful-git-branching-model/

[CapacitorSet]

The current branching model is similar, with master being the master branch, dev being the development branch, and es6 being a (huge) feature branch.

[blackdev1l]

Similar, not the same, there are specific rules about the branching model... They are made to solve these specific problems

[CapacitorSet]

Which problems?

[blackdev1l]

Conflicts resolution, branching policy, versioning of the product.

master should be at least the stable - production ready - state of the project, and dev(elop) the current -bleeding edge- state of the project, if es6 is the feature branch then it should be merged to develop and then to master when the feature is ready, if the feature branch takes too long it should be split in various small feature branch easy to merge,
An optimal solution would be to merge es6 to dev and then start to create feature branch for every plugin or module to port in es6, so you can start to write a roadmap and understand how much of the project has been ported and set some mile stone for the versioning phase

[crisbal]

Right now the project is in a strage state.

master is the production branch
dev is the development branch related to master
and es6 is a whole new branch, not related to master and to dev.

dev is some commits ahead of master
es6 is a complete rewrite, no common code, no common commits. the whole thing will be merged into master whenever I fell like it and the merge will be --force, there is no need to handle merging issues.

[crisbal]

After this the branching model will be:

• master run the stable version
• dev will be the development version
• gh-pages will be used to host the website

addittional branches might be created for custom code and custom things but these will need to be kept updated by their mainteiners

[blackdev1l]

So, for further development which one is the correct? Because if es6 is a rewrite and dev is commits ahead...? Also if you gonna merge --force there's no need to dev anyway

[crisbal]

You have to develop on es6.

You can develop on dev but won't merge it to master, no point in it.

Dev is the version running on my raspberrypi/FactotumBot but it is not stable in a sense it is not documented and working

[blackdev1l]

Then, the real dev is es6 and the current dev is just customization based on your deploy, now i get it.

[crisbal]

dev is no customization, as I said it has some new features not stable for master. But all the development is taking place in es6, as I said.

[CapacitorSet]

Why close this issue? It still requires work (i.e. merging the branches when they're ready).

[CapacitorSet]

With all features successfully copied over, I closed dev.

Discussion about the branching model will take place in #107; I invite everyone to chime in.