I agree that the main focus must be to get a 2.2 release. So the
question is what to do with the real blocks. They are currently rather
close to the "specification", but we don't know if the specification is
good enough without getting experience from the blocks.
For ditching the environment abstraction, that should of course not
block any releases. It can always be solved by making the change in a
branch and merge it back when it works.
/Daniel
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
And for me the most important question :) What is the suggested
timeframe/version for this? Do you want to do this for 2.2?
It depends on the timeframe for 2.2 ;) I will be offline for the next
two weeks (kitesurfing in Mexico :) ) after that I would like to ditch
the enviroment abstraction ASAP.
So it sounds like 2.2.
Hmm, ok, this is a point where I disagree :) I think we should get 2.2
out asap to have our mind clear for new stuff. Of course, you're right
that if we plan to develop 2.2 for another year, we can ditch the
abstraction as well. But I really fear that in that case we never get
2.2 out.
I strongly suggest that we start creating roadmaps. This also would make
the development of Cocoon for users much more transparent. Currently I
have only two points which I really think have to be finished for 2.2:
the build/deployment stuff and making the current blocks available
separatly/providing an own versioning for them. So as soon as the m2
integration works, we can polish 2.2 a little bit and then release the
core and each blocks as 2.2 and from the on develop the core and the
blocks independently and release them independently. Everything else can
follow later on.
WDYT?
Carsten
