README

ro-manager

This project is a command-line Research Object management tool, following the specification at http://www.wf4ever-project.org/wiki/display/docs/RO+management+tool, which is in turn derived from http://www.wf4ever-project.org/wiki/display/docs/RO+command+line+tool.  Details of the command line interface are expected to evolve as the software is developed.

Documentation about using the tool is at http://wf4ever.github.com/ro-manager/doc/RO-manager.html and http://www.wf4ever-project.org/wiki/display/docs/RO+Manager+FAQ.  (As of October 2012, the FAQ documentation is more up to date.)

Installation instructions can be found in the README file in the "src" directory (https://github.com/wf4ever/ro-manager/blob/master/src/README.md).

* * *

As a first step to using "gitflow" branching structures (http://nvie.com/posts/a-successful-git-branching-model/)
a "develop" branch has been created.  In due course, the "master" branch should only ever contain production code
that has been published to PyPI.

I have not yet created branches for releases or feature development
I'm taking a view that these can be created as required.
Many developments may take place on a local branch and be pushed straight back to "develop".

* * *

## Some git incantations ##

See:
* http://nvie.com/posts/a-successful-git-branching-model/


### Create the develop branch ###

See:
* http://www.linux-pages.com/2011/05/how-to-create-a-brand-new-git-tracking-branch-from-scratch/

  git push origin master:develop
  git branch --track develop origin/develop

Also, to delete remote branch:
  $ git push origin --delete <branchName>


### Creating a feature branch ###

When starting work on a new feature, branch off from the develop branch.

  $ git checkout -b myfeature develop
  Switched to a new branch "myfeature"

Also:
  $ git push origin HEAD

Pushes to same-name branch at origin repo


### Incorporating a finished feature on develop ###

Finished features may be merged into the develop branch definitely add them to the upcoming release:

  $ git checkout develop
  Switched to branch 'develop'
  $ git merge --no-ff myfeature
  Updating ea1b82a..05e9557
  (Summary of changes)
  $ git branch -d myfeature
  Deleted branch myfeature (was 05e9557).
  $ git push origin develop

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward.


### Creating a release branch ###

Release branches are created from the develop branch. For example, say version 1.1.5 is the current production release and we have a big release coming up. The state of develop is ready for the “next release” and we have decided that this will become version 1.2 (rather than 1.1.6 or 2.0). So we branch off and give the release branch a name reflecting the new version number:
  $ git checkout -b release-1.2 develop
  Switched to a new branch "release-1.2"
  $ ./bump-version.sh 1.2
  Files modified successfully, version bumped to 1.2.
  $ git commit -a -m "Bumped version number to 1.2"
  [release-1.2 74d9424] Bumped version number to 1.2
  1 files changed, 1 insertions(+), 1 deletions(-)


### Release branches ###

May branch off from: develop
Must merge back into: develop and master
Branch naming convention: release-*

Creating a release branch

  $ git checkout -b release-1.2 develop
  Switched to a new branch "release-1.2"
  $ ./bump-version.sh 1.2
  Files modified successfully, version bumped to 1.2.
  $ git commit -a -m "Bumped version number to 1.2"
  [release-1.2 74d9424] Bumped version number to 1.2
  1 files changed, 1 insertions(+), 1 deletions(-)

Finishing a release branch

  $ git checkout master
  Switched to branch 'master'
  $ git merge --no-ff release-1.2
  Merge made by recursive.
  (Summary of changes)
  $ git tag -a 1.2

  $ git checkout develop
  Switched to branch 'develop'
  $ git merge --no-ff release-1.2
  Merge made by recursive.
  (Summary of changes)

  $ git branch -d release-1.2
  Deleted branch release-1.2 (was ff452fe).