I think that going for option 1 is the best approach. The new NonSequentialParser PDFBOX-1199 is a huge step forwards reusing the 'old' codebase and overcoming the main issues resolving from the fact that the old parser was sequential and not in line with how PDFs are build.
Working on the ConformingParser I've outlined my approach in PDFBOX-1000. As I don't want to simply take existing code without revisiting it and making sure that conformance is met I agree with Timo's point that this might affect a couple of internal classes. So this is a longer term goal. With regards to the ConformingParser it would be good to get some more feedback about the current approach as moving forward with ConformingParser -> SimpleParser -> PDFLexer it will create a lot of effort if we revisit that design decision. So from that doing a 1.7.x release using the current trunk will provide a lot of benefits and leave time for redoing a new parser 'from scratch'. BR Maruan Am 09.04.2012 um 13:30 schrieb Timo Boehme: > Hi, > > I do also prefer option 1. For the conforming parser to be cleanly integrated > I assume we will have to adjust a couple of internal classes thus we really > should have one (or more) releases before this major release with the 'old' > code base. > > With the new intermediate 'conforming' parser (PDFBOX-1199) I think we should > do a 1.7.x release. While creating a branch to separate next major release > would be a cleaner solution I'm afraid that maintaining two branches is > currently not doable with the available resources. > > > Best regards, > Timo > > > Am 08.04.2012 21:26, schrieb Andreas Lehmkuehler: >> when preparing the next board report I was wondering what to write about >> our plans for the next release. >> >> I guess it's obvious that sooner or later we will go for a 2.x release. >> The major release may include the following >> >> - merge/replace Jempbox/Xmpbox >> - remove deprecated stuff >> - move to java6 as minimum requirement >> - switch to the (completed?) conforming parser as default >> - .... >> >> IMO we have different options how to do that: >> >> 1. >> >> Release a 1.7.x version based on the current trunk. Start with the major >> release using the current trunk. >> >> pros: >> >> - new feature release after 9 months >> - 1.7.x release without much effort >> - enough time for the major release >> - ... >> >> cons: >> >> - 2 XMP libs >> - unstable conforming parser >> - ... >> >> 2. >> >> Choose a couple of improvements/fixes from the trunk and apply them to >> the 1.6 branch and release a 1.6.x bugfix or a 1.7.0 feature release. >> Start with the major release using the current trunk. >> >> pros: >> >> - new feature/bugfix release only with chosen features/fixes >> - enough time for the major release >> - no unstable conforming parser, as it wouldn't be part of the release >> - ... >> >> cons: >> >> - 2 XMP libs (if we would do a 1.7.0 release including preflight) >> - a lot of discussion on what will be part of the release and what won't be >> - a lot of work to create the release compaired to alternative 1 >> - ... >> >> 3. >> >> Drop all 1.6.x/1.7.0 plans and start with the major release using the >> current trunk. >> >> pros: >> >> - we wouldn't have to spend time on a 1.6.x/1.7.0 release >> - ... >> >> cons: >> >> - too much time without release >> - too less time to work on the new major release, because of con 1 >> - ... >> >> I prefer option 1, what do you think? >> >> BR >> Andreas Lehmkühler > > > -- > > Timo Boehme > OntoChem GmbH > H.-Damerow-Str. 4 > 06120 Halle/Saale > T: +49 345 4780474 > F: +49 345 4780471 > timo.boe...@ontochem.com > > _____________________________________________________________________ > > OntoChem GmbH > Geschäftsführer: Dr. Lutz Weber > Sitz: Halle / Saale > Registergericht: Stendal > Registernummer: HRB 215461 > _____________________________________________________________________ >
