Hi all, last week I fixed some issues in LDPath (MARMOTTA-197, MARMOTTA-221) which should be also backported to a future 3.0.1 bugfix-release.
To keep track of such things I propose the following branching workflow for releases and backports: At the moment, we have two branches in the git-repository: master and develop. - All development should be done in the develop-branch. This is also the branch that is tracked by the jenkins server. - When we feel it is time for the next release, develop is merged into the master-branch, where the actual release process then takes place. (tag, update of version numbers, release-process related fixes (N&L), etc.) - In the meantime, development can continue on the develop branch. - After a successful release (vote has passed), the changes in master are merged back into develop. - For backports/bugfixes in a released version, we start a new branch from the release-tag (e.g. "3.0.x-bugfix" for the 3.0.0-incubating release) where the bugfixes are applied. From this branch we can then do the bugfix releases (e.g. 3.0.1-incubating). - Changes to the bugfix-branch(es) should be done by cherry-picking [1] commits from the develop branch (as far as this is possible). Use the -x option! So, what do you think? Best Jakob [1] <https://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html>
