Hi, Am 19.04.2013 um 09:47 schrieb Timo Boehme <timo.boe...@ontochem.com>:
> Hi, > > since it is quite clear that we will have API incompatible changes in 2.x vs. > 1.x we need to keep a 1.x branch for further bug-fixing/small improvements > also after 2.0. From my point of view the trunk should reflect the most > up-to-date development which means 2.x and 1.x would have its own branch. > Only if we agree that 2.0 is a very long term goal and we may have quite a > number of improvements in 1.x in the mean time it would be better to keep the > trunk for 1.x. Good point - if we can ensure short release cycles I agree that 2.0 should be based on trunk and 1.x will be branched. > > However as Thomas wrote not all improvements we plan have to land in 2.0, but > 2.0 may be a starting point with better basics to start from and thus 2.0 > maybe is not a so long term goal. > > The need for branching will arise with the first API incompatible change or > an improvement we don't want to maintain in 1.x should be integrated. > > For the 2.0 features: > - switch to Java 1.6 > - my main interest is in the parsing part and here I would like to see > the current parsers be replaced by a cleaner approach Maruan has > started with together with parsing on demand; To me that's also one of the targets for 2.x - the reason why I proposed a step before (modularization, rearrangement of dependencies) is to have a stable API at least at the PD level so we can work on the 'internals' wo affecting the typical user. > in 2.0 this parser might not be able to parse all documents we can > handle in 1.x but can be improved later; IMHO the parsing goal should be o parse pdfs conforming to the spec o parse on demand, incremental parsing, forward parsing only (from a page perspective) o annotate/tag/handle properties, methods … on a PDF version level o add hooks to allow for handling parsing exceptions to deal with real world PDFs which are not conforming > this kind of parsing will also require changes and refactoring at the > COS level; defining an API here we can build on should be part of 2.0 > Does the COS level API has to be stable? Is that the 'official' API typical users are working with? Agreed that we need to clean it up. There I would like to see that the COS object becomes more intelligent so the parser deals with the overall structure, the COS object with the information for itself. This for deserializing/serializing from/into tokens. In addition the methods within the COS objects should be similar e.g. COSNumber has a get method to parse a string COSString doesn't. There parsing can be done within the constructor … > > Best regards, > Timo > > > Am 18.04.2013 23:32, schrieb Andreas Lehmkuehler: >> Hi, >> >> Am 18.04.2013 22:15, schrieb Maruan Sahyoun: >>> I'd think that we should start scoping out 2.0 - what will be covered >>> under that topic. >> > In addition I would see us doing additional bug fix releases and >> minor enhancements prior >> > to releasing 2.0. My preference would be to branch out 2.0 and keep >> trunk for >> > working on 1.x >> Hmm, we already have a 1.8 branch, which can be used for further bugfix >> releases. Do you want to use the 1.x trunk for a possible 1.9 release? >> >>> as this would be clearer but maybe we should postpone that discussion >>> until >>> we have a better understanding what 2.0 means. >> I don't want to start a discussion about possible changes at this point. >> Whatever we will do, I'm pretty sure that there will be some api changes >> and >> we should use this fact as basis for our discussion if we branch or not. >> >>> Maruan Sahyoun >>> >>> >>> Am 18.04.2013 um 21:11 schrieb Andreas Lehmkuehler <andr...@lehmi.de>: >>> >>>> Hi, >>>> >>>> what is our next target after releasing 1.8.0 and 1.8.1? >>>> >>>> We already started some discussions about that topic, but I'd like to >>>> have >>>> clarification. Is it time to go for a 2.0 version? If we agree to >>>> that goal, >>>> how should we proceed? Should we branch or simply use the trunk? >>>> >>>> I'd prefer to continue using the trunk. We are still able to release >>>> bugfix versions using the 1.8-branch. Even a new 1.9 feature release >>>> should be possible by branching the 1.8-branch. >>>> >>>> WDYT? >>>> >>>> BR >>>> Andreas Lehmkühler >> >> 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 > _____________________________________________________________________ >
