Hi all, I agree with Timo, pdfbox is not (yet) a big project so releasing per module will cost too many. We can have modules definition and numbering that permit to do separate releases in the futur even if we do not for the moment.
Guillaume Le 29 mars 2013 15:35, "timo.boe...@ontochem.com" <timo.boe...@ontochem.com> a écrit : > 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 >
