Re: Stable/Unstable and CVS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, this is not the first time we talk about branching. I have not
worked with branches before, so I feel a bit scared about it. Is it easy
to merge, and apply bug fixes from an unstable branch to the stable
branch, for example?

If so, then go for it. We are just waiting for someone brave enough to
give it a try and guide us!

Tomorrow I'll be taking a look at the link you gave, thanks.

I think Sourceforge is beginning to offer Subversion service. I think
branching is easier and cleaner in subversion. Should we try to move to
subversion?

Greets.


Harry Vennik wrote:
> 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
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
> 


- --

(================================)
      Alvaro J. Iradier Muro
        airadier@xxxxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD2sOIoDlUrRluukQRAutVAJwNQ4Mm3BJWDDcPuqJqtA2sOWOSYQCgvA8J
Um7bJ2hchIsTxNKQi/zpPB8=
=5pzj
-----END PGP SIGNATURE-----


-------------------------------------------------------
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