Carsten Ziegeler pisze:
Ok, all this is definitly not optimal and it now pays back that we never
paid enough attention when the various parts were developed by different
people.
I understand your frustration and I would opt for clearing everything up
in your situation as well.
I personally have no problems with breaking the contracts for 2.2 in
some places if it makes sense. We changed already a lot of things, so
why not changing some more? The question is do we loose users just
because of this? I don't think so.
BUT, there is still no final release of 2.2 and it's not even visible
when this will happen. Such changes will create the nice and easy
argument to delay the release further. I still would prefer to release
2.2 *today* (well today is not feasible, but let's say in the next 7
days) and directly afterwards do this refactoring.
+10000.
Not changing the environment abstraction is a mistake, but not releasing
is imho a much bigger one.
Do you remember that we have released RC1 but have not announced it yet? The only reason for this situation is that we don't have new site
published yet. There is no documentation about C2.2 officially published so it's nonsense to announce it.
Now, we have to decide what to do. I would be very happy to help with documentation but it means I would have to neglect my GSoC tasks. I
have no problem with it because days without Cocoon's internals could be much brighter ;)
However, investing my GSoC time into writing documentation seems to violate agreement with both Cocoon community and Google Summer of Code
organizers. I made a promise to work on unification of Object Model and Expression handling to Cocoon community. Moreover, SoC has its own
opinion on working on documentation[1]. Of course we could say that I've already contributed some code and it does not harms that much if I
spend few days only on documentation. What's your opinion?
I'm speaking about it because I would like to release Cocoon 2.2 soon, too.
Then my preference is to take following steps:
1. Release 2.1.11 and almost completely freeze 2.1.x branch. We could agree
to allow only critical fixes to go there.
2. Release 2.2 version of core and 1.0 version of various blocks. Move cocoon-core:2.2 to maintenance branch and allow bug fixes and
small improvements. Same for blocks released as 1.0.
3. We could start development of cocoon-core:2.3 in trunk. Blocks that would depend on cocoon-core:2.3 could be released as 1.1.0 because
it's a major change to their dependency. Of course, if block is changed significantly in some other way than change in dependencies it would
be released as 1.1.0 too.
I also think that we could release cocoon-core:2.3 just after I finish changes to Object Model and Expression handling so people can benefit
from it right away.
WDYT?
[1] http://code.google.com/support/bin/answer.py?answer=60315&topic=10727
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
