I have to say I agree with pretty much everything in your message. I
like the premise of it as it makes us assume that as soon as code is put
out there that it is being used. In my opinion, this creates a much more
customer oriented mentality because you are going to get yelled at a lot
when you start breaking compatibility.
Ralph
Daniel Fagerstrom wrote:
Jorg Heymans wrote:
Daniel Fagerstrom wrote:
For 2.1.x (that we hopefully will kill soon), we could do something
99.99% of our userbase is using it, no need to make them jump out of the
window with statements like this ;)
What we have discussed on the list and seem to an agreement about, is
that we will try to release a last (or something like that) relase in
the 2.1.x series after the GT. Then we will also release a 2.2 alpha.
During the alpha stage of 2.2, early adaptors will hopefully identify
all unplanned incompabilities so that we can correct them. And for
planned incompabilities we will provide migration instructions. The
2.1.x will not be killed until we can offer a stable 2.2 (or maybe
later than that).
After 2.1.x we will hopefully be able to have binary releases and
separate release cycles for all blocks. This will make it easier to
make new releases, and easier to keep instalations up to date. It
will also increase the preasure on keeping stable contracts on blocks.
We will hopefully be able to abandon our current use of "global"
branches. There will be just one trunk version on nearly all of the
blocks. New functionality will either be introduced by creating a new
block, within an existing block or if it is impossible to avoid by
having a development branch of a specific block.
As I have discussed before "stable" branches doesn't lead to stability
as one might believe. Software becomes stable when many people use it.
By calling something an unstable branch it will become unstable as
none use it. It is better to just have a trunk and develop in an
incremental and evolutionary way. In this way trouble will be detected
early when it easy to fix. It will also motivate us to have so much
automatic testing that the trunk will be stable.
--- o0o ---
I use drastic formulations like the one above because I'm impatient
and want all the new goodies right away ;)
I don't think users have to worry, rather the oposite. We are heading
towards a less monolithic and more scalable Cocoon, that will be much
easier to maintain and to keep up to date.
/Daniel
