cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: 2.1.8 (Was: Re: JING Transformer...)
Date Wed, 31 Aug 2005 17:58:31 GMT
Ralph Goers wrote:

> So while you can argue about frequent releases or whatever, I still want 
> a forms framework that this community is willing to call "stable".

A few things:

  1) the simple fact of calling something stable doesn't make it stable, 
but it *does* in fact alter the perception of those using it. Commercial 
companies ship software as final when they know it's not. Some distros 
ship x.0 and people know it's really a beta. We don't do betas anymore 
because we know people stay away from those and you need the real-life 
test to find the real bugs.

  2) this is open source. you get what you pay for. And, yes, I foresee 
that companies that will do regression tests on projects that, for one 
reason or another, fail to do that property or extensively, will make a 
good living out of that... but their developer's lifes will be miserable 
and their burn out cycle might kill them before the profit margins start 
to kick in (not to mention the continuous friction with the community, 
if they keep those regression tests for themselves).

  3) blocks are not properly versioned, because we need real blocks for 
that. If we had real blocks, we could have two branches: a bugfix one 
and a development one, just like we do for the trunk, and backport stuff 
when it makes sense. In this scenario, Ralph will happily use the bugfix 
branch and Sylvain will happily hack ajax into the development branch 
and everybody is happy, as CForms have their its own release cycle and 
version control.

  4) software stability is a myth, it's never there, but continue to 
call something 'unstable' to avoid justifying lack of back compatibility 
is not a good excuse, not after so many years of being there and being used.

So, here is what I suggest:

  1) we attach a label to a 'branch' of a block, not to the block itself.

  2) labels should not be 'stable', 'unstable' but 'bugfix' and 
'development', or something equivalently neutral in respect of stability 
which is normally perceived as a measure of how well it remains working 
in real life rather than how solid its contracts are (not everybody 
thinks in terms of SoC like we do, especially not their managers and 
CTOs, anyway). Or we could use the linux style of using odd/even numbers 
to signify taht without having to find an appropriate name for it.

  3) start having two branches for the blocks that require it (cforms is 
a good candidate), then decide what branch to ship with what version.

Comments?

-- 
Stefano.


Mime
View raw message