On 8 Jan 2004, at 15:57, Sylvain Wallez wrote:
So the question is: aren't we moving towards a 3.0 release?
I think that keeping 2.2 as a target keeps people focusing on back-compatibility while saying "3.0" upfront might scare users and give a false sense of freedom to break things to developers.
Even if changes are rather huge between 2.x versions, this will just please people. We don't need the marketing of big numbers for our users to understand why upgrading is good for them.
I mean, give them blocks and they will change to 2.2 overnight... but only if their things will work just fine.
What Carsten is proposing impacts probably 0% of our user base. Not only it's deep and undocumented... but it's stuff that even hard core cocoon devs know and date to touch... in case a super-power-user has used it, he/she will write to us and we'll tell him/her what to do.
I think impacting 0% of our userbase cannot be considered 'breaking back compatibility".
Keep in mind that this list is actively watched: if we were to break compatibility with stuff that a lot of people depend on, we'll sure hear from them sooner rather than later.
So I think the way we are moving on is just the optimal one: incremental action, keep back compatibility at maximum, but cleanup where required and listen for complains from the balcony when doing so.
Ok. I was playing the picky guy that you know I can play so well, and did not wanted to frighten anyone. What I was expressing is that stricly speaking, changing the "y" number in "x.y.z" means that backwards compatibility is ensured with lower values of "y". Now I agree the points under discussion are very advanced and low level areas of the Cocoon core, some of which I never used myself, and therefore this should not impact that much people.
But this once again outlines the real need we have to clearly specify what we consider as publicly and officially supported APIs or private low-level contracts that are needed to implement the Cocoon core but that should not be safely relied upon since they may change if the Cocoon core changes.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
