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.

Reply via email to