Upayavira wrote:
Carsten Ziegeler wrote:
<snip/>
Exactly - and we should try to make sense out of our version numbers especially wrt compatibility.
I think we should be keeping 2.1.X as stable as possible, and be tidying trunk.
Agree
We therefore need to be thinking about how to get trunk released within a reasonable time (6 months?),
Or sooner. What about setting a strict release date within 3 months and release what we actually have succeeded implementing, rather than wait untill all our dreams are fullfilled?
and therefore be prepared to delay some features until 2.3 if their development is going to take too long.
Exactly
After all, 2.1.X is a _maintenance_ branch, but that doesn't seem too much like how we're using it - we're adding stuff to it that should go in 2.2, only because we don't know when 2.2 will be out, we're not happy to just have it there.
We tried this for 2.0 -> 2.1 and I don't think anybody was happy with the result, i.e. having to either not using the new cool stuff or running production sites on based on alpha versions for maybe a year.
---o0o---
Is there a list on what incompabillities 2.2 introduces, so that we can evaluate the consequences of uppgrading?
There is a list on what 2.2 should include http://wiki.apache.org/cocoon/22Planning. Although it would be nice to have all that, I think that the Cocoon ECM is reason enough for us to release a 2.2.
When is Cocoon ECM ready for prime time?
For the Template refactoring, it really is a refactoring, so the idea is that it should continue to work as before at all times. So we should in principle be able to switch to it any time. Now having said that I would like to do some more refactoring steps, write some documentation and write some more test cases (please help me adding test cases), before I start a vote about switching. But it should certainly be ready for 2.2.
/Daniel
