[Vtigercrm-developers] 5.0.1, 5.1 releases

[Richie]

Jeff, I need your personal thoughts on our decision to have a 5.0.1 branch and keep the 5.1 development to be done on the top-of-the-trunk for 5.0.0. 
 
This will give us the extra-confidence here to move forward. 
 
I have some queries. Kindly bear with me as I did read the document but was not quick enough to understand it. 
 
The bug fixes that are being done will be on the 5.0.1 branch. Now, to maintain the same fixes in the 5.1, we also need to make checkins in the 5.0.0 top of the trunk. Is that correct? 
 
To add to the above combo, we can also integrate the contributions of other features for example the mailing list enhancement from mmbrich (say) to ONLY the top-of-the-trunk. 
So, in brief, the 5.0.0 top of the trunk will have the following :- 
 
the 5.0.0 code 
the bug fixes that are going to 5.0.1 
the features submitted newly 
 
The combination of these three is going to be called the 5.1 release. 
 
Is my understanding correct? 
 
Richie




---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- 

  Sergio A. Kessler wrote:
> I think this is wrong.
> I can understand (not agree) to create a 5.0.1 branch. but why you need
> to create a 5.1 branch at all ??? 5.1 development should be done in the
> trunk... branching 5.1 the only thing will do is complicate things...
> remember KISS (Keep It Simple, Stupid)

I was going to complement Richie on the right branching naming, etc,
procedure...

The timing of branching is equally important, however, and I think it's
too soon.

We're going to have to decide (and document, and enforce) among the
'stable trunk' vs other development models.

We need to decide where new features get developed, and under what
conditions they get merged back to the 'trunk' or branch, as policy
decides.

Everyone discussing this should read:

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html

with 'copies are cheap in subversion' in mind. Branches are easy, and the
numerous variety of branches (e.g for feature development) should be
short-lived (e.g. merge back to trunk or branch, then delete/move branch).

Maintaining multiple long-lived branches is labor intensive, and might
only be undertaken to support long-term maintenance goals, on branches
that rarely want to merge changes from 'upstream'.


_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060920/88a14e1f/attachment-0004.html