You're right that this is seems to be a problem for us, but to be honest I don't know why. We can make incompatible changes from 2.1 to 2.2 but we just should ensure that migrating an application is very easy. The first thing you need for this, is - tada - a documentation of incompatible changes and the second thing is plain simple: a migration tool that helps users.I think there is another explanation why there are so little changes: We are way more concerned about the stability of contracts. ...even for trunk!
Quite a few people now have live installations and seem to go for the "na, don't change it! it ain't really broken". This seems also seems to apply to trunk to some extend. Maybe everyone remembers the 1.x->2.x pain and wants to be able to upgrade easily. (this being said without any valuation)
The days are over when cocoon was more a research project and when noone really cared about fundamental changes to the contracts. ...the question is whether this is good or bad.
...at least it's one thing that slows down core development.
For example, NeXt (the company that developed the original MacOS X and was then 'bought' by Apple), did incompatible changes in their APIs for their libraries between minor version. So while your code was still binary compatible (as libraries were nicely versioned), your source code just didn't compile anymore. But developers didn't complain, just because NeXt did a good job in documenting things (so a developer understood why something changed and in the end loved NeXt for changing it :) ) and they provided a tool that simply changed your source code and replaced for example the old method names with the new ones etc.
So, for example if we *would* introduce a new format for the cocoon.xconf (and I hope that we are *not* doing this), then we could just build a simple tool that transforms the old one into the new one and explain the benefits of the new format and everyone will love this (ok, at least in theory this works...)
SO we shouldn't hesitate to make incompatible changes, but we should ensure that migration remains easy.
Carsten
-- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
