Xmipp

Xmipp releases management

Setting the version number

Xmipp version number (for example, "3.1" appears in different files across the source code. You can change the number in all of them easily with the set_xmipp_version.sh script

Release branches policy

The new branch release should be handled carefully when release deadline is near. Ideally, only bug fixes should be commited to that branch.

New features can be added to the master branch.

Example: preparing the 3.1 release

Until 3.1 release is tagged (his state is frozen), master and 3.1 branches will coexist and everyone must deal with both. Some of the changes (3.1 bug fixing) will be only for 3.1, and some of them will be new features for 3.2 future release. This is a brief guide to “how to push changes to our repository without destroying Kino's timetable”:

Option 1: I've seen a bug in Xmipp and I want it solved for 3.1 version

Step 1: Ask Josemi whether that is really a 3.1 bug or a new feature. If yes continue with Step 2.

Step 2: Write your changes in 3.1 branch.

Step 3: Commit them to your local 3.1 branch.

Step 4: Push them to remote repository.

Step 5: Merge your local 3.1 with your local master

Step 6: Push master


> ALARM: I fixed the bug on master (without committing them), what can I do now?

Substep 1: git stash your changes, move to 3.1 and unstash them

$ git  stash
$ git checkout 3.1
$ git stash pop

Substep 2: commit your changes and push them


> ALARM: I fixed the bug on master (committing them but not pushing them), what can I do?

Substep 1: git cherry-pick your changes from master to 3.1

$ git  log

Note your commit hash

$ git  checkout 3.1
$ git cherry-pick <your_commit(s)_hash(s)>

Substep 2: push your changes

Option 2: I want to add a new feature in Xmipp

Step 1: Don't touch 3.1 at all. Work on master branch.


> ALARM: I committed (without pushing) a new feature on 3.1. What can I do?

Substep 1: git cherry-pick your commits from 3.1 to master

$ git log

Note your commit(s) hash(s) and the last commit before your changes

$ git checkout master
$ git cherry-pick <your_commit(s)_hash(s)>

Substep 2: reset your 3.1 branch state

$ git checkout 3.1
$ git reset --hard <commit_before_your_changes_hash>


> ALARM: I pushed a new feature on 3.1. What can I do? Do I deserve suicide? (yes)

Substep 1: git cherry-pick your commits from 3.1 to master

$ git log

Note your commit(s) hash(s)

$ git checkout master
$ git cherry-pick <your_commit(s)_hash(s)>

Substep 2: revert your mess in the 3.1 branch

$ git revert <older_commit_hash>^..<newer_commit_hash>

(where older_commit_hash and newer_commit_hash are the first and last commits of the range of commits you want to destroy). In case of a single commit, just git revert

لطفا وحید، بررسی مرتکب خود را !!!!!!!!!!!!!

-- JesusCuenca - 2013-10-18