Hi, I think that doing a release is quite a bit of work and having multiple modules with separate releases each requires extra time. As long as there are no module specific maintainers with responsibilities for releases we should do releases with the complete module set. This also prevents problems with incompatibilities between the modules.
BR Timo > Maruan Sahyoun <sahy...@fileaffairs.de> hat am 29. März 2013 um 14:15 > geschrieben: > Am 29.03.2013 um 13:18 schrieb Andreas Lehmkuehler <andr...@lehmi.de>: > <SNIP> > >> One thing to consider is how we handle releases afterwards. Will we always > >> release > > > all modules as part of a release (like Apache Camel does) or do releases > > > seperately (as Apache Sling does). > > That's a good point, but it'll depend on the details. AFAIK Sling is OSGI > > based > > so that all components should be independent, which makes it easier to > > release > > them separately. > > Correct Sling is OSGI based. But Apache Camel also has a core component on > which others are based. And they had a similar discussion. I don't think it's > a technical question as if we go for modules within minor releases API's > should stay stable so e.g. PDFReader could count on PDFParser. But as a start > why don't release all modules together and revisit that question later. > > >> I'm happy to help with implementation/rearrangement as soon as the > >> transition to the CMS is done > > Cool! > > > > BR > > Andreas Lehmkühler > > BR > Maruan Sahyoun
