Post-release development

After the first release (or maybe actually a little before that) of this software is published, we should move to a more structured workflow scheme. After I googled for best practices in this, I propose to have this model:

• The master branch with the stable version
  • hotfix-*branches branched from master and merged to both master and dev.
• A dev branch, which would contain the new features and changes
  • Feature branches branched from this branch, rebased on this branch before merge
• release-* branches created from the dev branch with desired changes for a new release.
  • Only bug fixes should be committed to these branches. (And when they are, they should be merged back to dev as well.)
  • These branches, when tested, are merged to master

Here (http://nvie.com/posts/a-successful-git-branching-model/) is a nice example with a picture.

In the article, there is also a suggestion to use merge everywhere (no mention of rebase), and to use merge with the --no-ff option, which creates a merge commit even if it’s not necessary. I’d like to put this to discussion. (I am in favor of the rebase+merge workflow as we are used to now… In case of the feature branches only, of course.)

As soon as this is discussed, I’d switch to the selected scheme so we could prepare the first release for the WMT 17 Neural Training Task

[jindrahelcl]

To sum this up:

• use semantic versioning (already adopted in the first release)
• keep using Github workflow
• create release for PyPI (for 0.1.1)

If you all agree, we can close this issue.

[kocmitom]

I do not have any opinion on this topic (except that I also want the github workflow, but as I see it is proposed). Therefore as for me, you can close it

I would like to have development as simple as possible 😃