Jorg Heymans wrote: > > > Carsten Ziegeler wrote: > >> >> 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. >> > > > I've been working a bit more behind the scenes lately to get excalibur > to behave properly under m2. I am currently switching the flat layout in > the whiteboard to the new excalibur poms to see how they behave and do > first tests. Once i'm done there i can focus more on the deployment > integration again. > > What about the repository reorganisation I suggested in [1]? Given a > more flat and m2 consistent layout, i can *easily* put it under > continuum control like i did with excalibur [2]. Note that we wouldn't > use continuum's CI features as such, but merely use it as an automated > snapshot release tool. It would thus replace my cronned shell script for > doing snapshot releases and make it possible to force a snapshot release > at the click of a button. > > The only thing about the repo reorg is that i don't want to stall > current development momentum, but frankly i don't really see a way not > to - at least for a few days.
For me, the absolute most important thing is getting the build working again with the excalibur stuff. I'm here at ApacheCon with Maven chaps around, and the easier it is for me to 'grok' the current Maven setup, the more likely I am to be able to understand and explore with them where we should go next. > Also: are we carrying forward all blocks to 2.2 or is this the time > where we ditch the obscure, rarely used and "blocks that don't really > deserve to be a block" blocks? I'ld say we choose the 10 most often used > and well known blocks and let the users voice their concern about those > blocks we aren't taking forward. If enough noise, we can then still > decide to support these blocks ourselves again or even offer it to > dedicated users to maintain themselves. See separate mail. Upayavira
