Re: The 0.18.0 release and Repository Rules

> 1) When and how we should create and distribute patch files
> 2) Under what circumstances we should create branches in the repository
> for in progress features
> 3) Whether or not bug fix releases should be done on a branch and when
> that branch should be made

I feel unconfortable with patches because I make a lot of confusion with them, 
and every time the repository changes you have to adjust patches because, as 
far as I know, patches are much less forgiving that CVS merge if there are 
big code changes.

I was thinking of a simple CVS process like this:

1) The main CVS trunk contains only the latest stable release (let's say as 
for now 0_17_0).

2) As soon as a new release is released a new bugfix branch is created (ex 
moto_0_18_0_fix) and a new devel branch is created (ex moto_0_19_0_dev). 
Small bug fixes and optimizations go to moto_0_18_0_fix  while new features 
go to moto_0_19_0_dev.

3) When new features and bug fixing come to a close, we 
	- FREEZE
	- branch tag MAIN with "cvs tag -b moto_0_19_0_pre" and we try merging 
moto_0_19_0_pre with moto_0_18_0_fix  and with moto_0_19_0_dev.

4) If everything goes well and testing is ok, we merge MAIN with with 
moto_0_18_0_fix  and with moto_0_19_0_dev.

This way we have several advantages:

1) We keep bug fixing and new features separate.
2) We always have a working and stable copy ready to be branched.
3) We have two branches (fix and dev) ready for testing before they are 
released.
4) We have a "pre" branch ready for testing too, with bugfixes and 
new_features inside.
5) We give visitors from outer worlds the impression that there are thousands 
of us out there.

Of course developers could keep a branch for themselves if they are working on 
something that can mess up things for others and merge it back just when they 
are ready to. Then, these private branches could be deleted after merge.

Stefano