Establish a build and release process

[dpalic]

right now the old build and release process looks very manual. We need to define, what we want to do in the future.

So my view:
I would stick to maven, even if I also see that gradle has done a great job, but many persons know maven and this makes it also easier for us to get rid of any "build usage issues".

regarding release process. I would like to have at least a branch per major release. Every released version should have at least a tagged/labled version in the repository too, so it is easy to recreate any issues from the tags and branches.

Of course the build and release process needs to be documented in the wiki as well, for:

• contributors
• users (how to build/rebuild)

[team172011]

I agree with your suggestion. So one master branch where the pull requests will be made into and for each release a new branch or tag?

[dpalic]

I would say we use the common practices without reinventing the wheel. We use it also for our team and it works.
https://gist.github.com/digitaljhelms/4287848
(pretty the same http://nvie.com/posts/a-successful-git-branching-model/)

in short we have a two main branches:

• develop => a always stable / evergreen branch for developing
• master => a always stable release branch, for releasing new version (here we have also the release tags like 1.0, 1.1, ...)

and a lot of supporting branches like:

• release branch to prepare a new release and to freeze any new features by branching away from develop
• hotfixes, to have a branch to hotfix a freshly release version
• feature branches (e.g. the PRs)

what do you mean?

[team172011]

Sounds good. I would say we should realise it with a transitional solution in the first step. Maybe making a first release with the following branches:

• master => a always stable release branch
• develop => a always stable / evergreen branch for developing (first also bug fix and other)
• mavn => repository for maven commit
• feature => (if needed) branches for bigger improvements/features