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.