Jump to content


Member Since 06 Oct 2011
Offline Last Active Nov 16 2016 10:16 AM

Topics I've Started

New mercurial workflow for Zurmo

23 October 2012 - 09:18 AM

I did some research on how we can standardize and improve our Mercurial process flow. I came to these conclusions:

There will be three main branches:
1. default - this will be our development (working) branch. We can often merge into this branch.
2. candidate - this branch will contain code that is ready to be released as stable(see release branch), but we merge it here for final testing. The default branch will be merged into this branch, but never directly into the release branch. If some bugs are found in the release branch, code must be fixed in the candidate branch and merged into the release branch.
3. release - this will contain only stable code. We will never commit changes into this branch. Code into this branch can be merged only from the candidate branch.

Additionally we will have feature branches, like we had until now, and feature branches can be merged only into the default branch and other featured branches.

Until now, we used only default branch and feature branches, so we merged everything into the default branch. When we discovered some bugs, the default branch was already a few commits ahead from the stable release, so we had to fix issues in the default branch, and tag some unwanted commits from the default branch into the new stable release.

Please share your opinions on this idea or suggestions.

We will probably start to use this approach after we release the next stable version(0.7.70).

Yii framework and RedBeanPHP files

14 August 2012 - 03:06 PM

Yii framework and RedBeanPHP are added into the Zurmo Bitbucket repository, so when you clone the Zurmo repository, you don't have to download Yii framework and RedBean. Also, there is no need to patch the RedBeanPHP file anymore.

But a small issue can happen in these cases:
1. When upgrading code to tip changeset in default branch, and then revert code to some previous changeset(that doesn't include Yii and redBean), Yii and RedBean folders will be deleted.
In this case you will have to download Yii and RedBean again, and patch RedBean(or update working copy again to tip changeset).
2. When upgrading code to tip changeset in default branch, and then switch to another branch, Yii and RedBean folders will be deleted(in case if you haven't merged them with default branch that includes Yii and RedBean files). In this case just merge current branch with default branch and everything will work fine.

Why we choose Mercurial/Bitbucket

09 April 2012 - 09:15 AM

A few people asked us why we choose Mercurial and Bitbucket, instead Git/Github.

First there was no doubt that we should use distributed version control system (DVCS), because of the power of branching/merging, ability to work offline and push your changes latter and many more.

There were two major DVCS players: Git, Mercurial, and from our perspective, both very powerful, reliable, so it was hard to make a decision.
When we choose Mercurial it was just personal preference, because Mercurial commands are easier to remember, because it is a bit more friendly to users who just starting to use DVCS, and because it has nice GUI tool for windows users, TortoiseHg.

Once we choose mercurial DVCS, the reason why we choose Bitbucket is obvious, because it offers free repository hosting for both public and private Mercurial repositories (and for Git repositories since a few months ago), so users can easily create new Zurmo forks, and make them private, without paying anything.

Difference between setUp() and setUpBeforeClass() for unit tests

27 January 2012 - 12:47 PM

I think it would be useful to mention difference between setUp() and setUpBeforeClass() methods whose can be found in most unit tests we are using.

setUpBeforeClass() method is executed only once per class, and even before object is constructed, and that is reason why it is marked as static public function.
setUp() method is called before every test case, which mean that this method can be called few times per one test class.

Similar is difference between tearDownAfterClass and tearDown(), tearDown() method is called after each test case, and tearDownAfterClass() method is called after all tests in class finish, and after last tearDown() method is called.