Dev-ops for parallel.js

[mathiasrw]

As commented in #148 (comment) some aspects should be discussed for everyone to be on the same page.

As mentioned in #126 (comment) and #123 (comment) I suggest we lean towards a git-flow inspired workflow because it has proven efficient.

I suggest the following:

• The master branch should only be updated when a new version has been released
• The develop branch is the branch we use between releases.
• For people not to accidently PR to master we have the develop branch as default branch. If people take the lib from git they will get the bleeding edge - but all documentation refer to the last stable CDN version.
• As we are many people around the table develop will be only be able to accept PRs with working travis testT hat way we avoid creating too many merge problems with each other while developing.
• Everyone does what they can to respect the time and efforts of the team.

[mathiasrw]

@MaXwellFalstein @amilajack

Inputs?

[mathiasrw]

@MaXwellFalstein @amilajack

Thoughts?

[amilajack]

Sorry for the late response. I'm held back on GitHub notifications.

I think this would be a great idea.

[MaXFalstein]

Yes, I agree with the setup. We should do periodic and git-flow based releases in line with the updates to the master branch.

[mathiasrw]

Awesome. Here is how I see the branches at the moment:

• revert-146-develop - Is this still active? can it be deleted?
• revert-142-develop - Is this still active? can it be deleted?
• dev-master - I suggest we work towards merging this into develop
• gh-pages - source for http://parallel.js.org - I suggest its stays like that.
• eslint-migration - branch to get the code linted - will be merged into develop when done
• feature/MaXwellFalstein - Branch to facilitate the code added by MaXwellFalstein
• feature/mergeFromMaxwell - Branch to facilitate the code added by MaXwellFalstein
  • develop - I suggest we get the last changes from master and make this the default branch
• master - at the moment the default branch. I suggest we only push to this on new version release after develop have been made the default branch.

@amilajack would you like to deal with revert-146-develop, revert-142-develop and dev-master when you have the time for it?

[amilajack]

Deleted the revert branches. Also i don't think there is anything in the dev-master branch but we have to check before deleting it. All my PR's are against the develop branch

[mathiasrw]

dev-master is 8 commits behind master. So if none of you are working on anything with dev-master I suggest we just let it go...

[amilajack]

Deleted it

[MaXFalstein]

I would delete the branch, if you are certain there is nothing of importance in the branch.

I am working on my branches - I will work on the MaX-Dev branch too for a few little gems :)

[mathiasrw]

Great!

Please confirm that no one is having any development on the master branch at the monent?

If not I will let develop get up to date with master and make develop the default

[amilajack]

Not sure if that is a good idea. See this. I'm a collaborator on that project and I think we made the right choice. Thoughts?

[mathiasrw]

I agree - you made the right choice.

The react-boilerplate repo is boilerplate code where part of the installation/usage process is described as:

Clone this repo using git clone --depth=1 https://github.com/mxstbr/react-boilerplate.git

so it makes very good sense to have master as default so the step does not include this more "scary" looking code:

git clone -b master --single-branch --depth=1 https://github.com/mxstbr/react-boilerplate.git

The intended use of Parallel.js is not to clone the repo but to use the lib via npm or (in future) via a CDN. By that, having master as default branch does not provide any benefit for the user of the lib, but it does have some setbacks:

• As master (in my suggestiong) is only updated on new releases, you cant make small ajustments and tweaks of the information on the front readme - that is still an important point of information for users of the lib. This can be avoided by having a "plain" readme refering to the parallel.js.org website.
• People contributing will (most?) often forget to point to the non-default branch develop and PRs will be more cumbersome.

If the arguments presented here does not transmit a good enough reason I suggest we keep master as default (as it is) but I do believe it will create unnecessary inconvenience.

[amilajack]

While we're working on v2, we'll need to update the readme for all the new api changes. So while v2 is in progress, people will be seeing the documentation for it instead of the currently released version. That doesnt really make much sense. react-boilerplate solved this issue by having a contributing.md, which a very common solution to this issue.

[mathiasrw]

Ok. Lets keep it.