Stable/Unstable and CVS

Hi,

The aMSN team is growing, and there is a lot of development going on. That is 
a very good thing of course, but over time, I think I noticed some growing 
pains. The core problem is that we are trying so much to keep cvs stable, 
while cvs is supposed to be the place where development is going on, which 
implies experiments, and thus unstable code. So, in fact, our way of doing 
things does not allow big experiments, or it requires us to make ways to 
enable or disable experimental features if we do some anyway. An obvious 
example is the 'if { protocol != 11 }' in the protocol code. This way we get 
real spaghetti code (for the protocol code is is said it was such already, 
but it must have grown even worse this way) and we even end up having 
unstable code in the release! (Unstable MSNP11 is in release 0.95, although 
it is disabled by default.)

Another way to do things exists, and is a better way I think.

That other way is: use the power of cvs better. Create a branche to do 
'unstable' development, and once the new thing gets 'stable', merge it back 
into the main trunc. As an example, I will take the protocol thing again. It 
could have been done this way if braches had been used:
- Everything is MSNP9, someone wants to start development of MSNP11. That 
person tags current cvs, and creates a new branch called 
BRANCH_UNSTABLE_PROTOCOL based on the tag.
- Same person starts a thread on the ML where anything going on in the branch 
is discussed. The initial mail on the thread should contain a description of 
what will be done (e.g. 'Implement a new version of the MSN protocol') and 
the name of the branch.
- MSNP11 development goes on in BRANCH_UNSTABLE_PROTOCOL. Things are just 
being changed. So, no if { protocol = ... } like we did in reality.
- A bug is discovered in MSNP9, and gets fixed in the MAIN trunc.
- Someone who is working on MSNP11 sees the fix in MAIN, and checks if it 
applies to MSNP11 too. If so, he will merge the fix into the branch.
- After some time MSNP11 is stable, and the changes get merged into MAIN. 
MSNP9 code is gone now. (No problem, because MSNP11 is stable, and MSNP9 thus 
unnecessary)
- Now the working on MSNP12 starts in BRANCH_UNSTABLE_PROTOCOL
- etc.

When working this way we can have only stable code in the MAIN, and unstable 
code in branches. Anyone can freely do anything he'd like to do, as long as 
people keep working in the proper branch. Before anything gets merged into 
MAIN, it will need to be discussed on this mailing list first. After some 
time, the project admin - Youness - closes the discussion and draws the 
conclusion 'approved' or 'needs more work' based on what was said in the 
discussion. If the conclusion was 'approved', the merge will be done.

Besides such unstable branches, we might also have stable branches. Those can 
be used for releases for example. This way we do not need demotivating long 
term feature freezes. Just freeze MAIN for a short term, create a release 
branch (e.g. for 0.96 that could be BRANCH_STABLE_0_96), and test what is in 
there for stability, and do the necessary bug fixes in that branch, while 
development of the next version (e.g. 0.97) starts in unstable branches. Any 
bug fixes get merged back into MAIN too of course. Once 0.96 is out, it could 
be that some bug appears that really needs to be fixed in a new release. We 
can than fix the bug in BRANCH_STABLE_0_96 and tag a 0.96.1 release from that 
branch.
Doing things that way we avoid what is going on now: we thought of releasing a 
0.95.1 as a bug fix release, but we will not be able to do such, because we 
added so many features already, that a new release based on the current code 
in cvs would not be a _bugfix_ release whatsoever.

What do you all think about using branches?

If anyone wants some doc about branches in CVS:
http://www.psc.edu/~semke/cvs_branches.html

Harry


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642