RE: Patch submission and release policy (Was: [PATCH] problems withHTTPS and base support for per message billing)

> Maybe it is also needed to establish of how many of the group
> should support or oppose to it before it is decided to what 
> will be added.

Something like this is needed when you have a one branch development.
when you branch the developers away from the stable release - why bother
? everyone who has CVS access can commit features as long as care is
take not to break anything and proper notification is done (current
devel-reports is more then enought - just remember to document your
changes in ChangeLog). only conceptual/architectual changes need to be
discussed in the open.

> >> > - branch the tree now (yesterday would have been a good 
> time too ;-)
> >> > and label it 1.2.0.
> 
> Why do you already want a branch??
> Why not putting the releases into a branch??
> (Just asking)
> Since this way you just can keep developing.
> 
> As for a release I would suggest name it 1.2.0
> Make a branch of it and do new releases as 1.2.x
> Continue development in the main branch for 1.3.y.

Semantics. I don't mind what you call it, as long as we have a stable
branch and a development branch. 

> > But for that, before thinking in branches and releases, we should
> > think in the new architecture.
> 
> I concur. The only thing is what kind of things do we put on the list.
> You already mentioned some. After what we have to define how indeed.

Why bother - you can't make architectual changes w/o branching the tree
- you need to get a declared stable release before rewriting the entire
code base, so people will have something to put on their production
servers while the project's next generation is in limbo.

--
Oded Arbel
m-Wise Inc.
[email protected]
(972)-67-340014
(972)-9-9581711 (ext: 116)

::..
Keep me away from the wisdom which does not cry,
the philosophy which does not laugh and the greatness
which does not bow before children.
	-- Kahlil Gibran