Hi, +1 for option 1.
Just 2 things to say : About java version, Most of the apache libs I use are compiled in java 5. Is there any policy on that topic for all apache project ? Maybe it could help to choose... About the 2 xmp libs, as one of the 2 version has never been released, we should spend some time to merge. Interfaces are not so different. BR, Guillaume On Tue, Apr 10, 2012 at 8:59 AM, Leleu Eric <eric.le...@atos.net> wrote: > Hi, > > I vote for the option 1 too. > > BR, > Eric > > -----Message d'origine----- > De : Timo Boehme [mailto:timo.boe...@ontochem.com] > Envoyé : lundi 9 avril 2012 13:31 > À : dev@pdfbox.apache.org > Cc : Andreas Lehmkuehler > Objet : Re: Next release(s)? > > > 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 > _____________________________________________________________________ > > > Ce message et les pièces jointes sont confidentiels et réservés à l'usage > exclusif de ses destinataires. Il peut également être protégé par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immédiatement l'expéditeur et de le détruire. L'intégrité du message ne > pouvant être assurée sur Internet, la responsabilité d'Atos ne pourra être > recherchée quant au contenu de ce message. Bien que les meilleurs efforts > soient faits pour maintenir cette transmission exempte de tout virus, > l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne > saurait être recherchée pour tout dommage résultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely > for the addressee; it may also be privileged. If you receive this e-mail in > error, please notify the sender immediately and destroy it. As its integrity > cannot be secured on the Internet, the Atos liability cannot be triggered for > the message content. Although the sender endeavours to maintain a computer > virus-free network, the sender does not warrant that this transmission is > virus-free and will not be liable for any damages resulting from any virus > transmitted. >
