Hi,
It seems that we have few choices : 1 - Postpone the release until an unknown date. 2 - Make the 1.7 release excluding the preflight module (and XMPBox ?) from the reactor pom. A Warning in the README.txt explains why the module isn't deployed in 1.7. 3 - Make the 1.7 release including preflight (and XMPBox?) with a specific version like "1.7-incubating". In addition, a warning in the README.txt explains that this module can evolve significantly. 4 - Make the 1.7 release with a warning in the README.txt For the three last options, all the code of the new preflight version will be done in a new package hierarchy. Both preflight versions will be fully independent. In version 1.8, Old version will be annoted as deprecated. In version 2.0, Old version will be removed. No choice is clearly satisfying but the best thing to do is probably the first one. If we can't wait, the clearest option for users is probably the third (incubating version of preflight (and may be XMPBox) ). What is your opinion ? BR, Eric 2012/5/23 Timo Boehme <[email protected]> > Hi, > > either way (excluding preflight or including it with warning) nothing > prevents us from releasing a 1.8 release in a not so long time frame with > the main addition a ready and usable preflight (and maybe first test > version of new parser). > > Timo > > > Am 23.05.2012 01:22, schrieb Ian Holsman: > > you could always put a big warning in the README, and mark >> xmpbox/preflight as deprecated. >> that should be sufficient for people not to use it while you work on >> doing the modification for 1.8. >> On May 23, 2012, at 7:11 AM, Guillaume Bailleul wrote: >> >> Hi, >>> >>> I agree with Andreas on that point : we should not release a code that >>> will be dead soon. >>> >>> preflight (and xmpbox) has never been released. So, in my opinion, >>> PDFBox 1.7 can be released without preflight... it bothers me for a >>> project but I think it is the best thing to do. >>> >>> There is more than one issue linked with that: >>> * Eric's new version will change the interface >>> * xmpbox and jempbox should be merged (or at least one should desappear). >>> >>> >>> The schedule with these modification is not compatible with 1.7 release. >>> >>> >>> Guillaume >>> >>> >>> On Tue, May 22, 2012 at 9:19 PM, Leleu Eric<[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> 2012/5/22 Andreas Lehmkuehler<[email protected]> >>>> >>>> Hi, >>>>> >>>>> Am 21.05.2012 20:38, schrieb Leleu Eric: >>>>> >>>>> Hi, >>>>> >>>>>> >>>>>> I discussed with Guillaume about the Preflight refactoring and we have >>>>>> some >>>>>> questions about le preflight module and the next release. >>>>>> >>>>>> Hmmm, last minute timing .... I planned to cut the release now. >>>>> >>>>> >>>>> I'm sorry :( >>>> >>>> >>>> >>>>> The "new" preflight implementation will be more flexible and >>>>> configurable. >>>>> >>>>>> But it will have significant impact on the current implementation. >>>>>> (New >>>>>> interface, new way to load/validate the pdf...) >>>>>> >>>>>> Due to the 1.7 release that is coming soon, we would like to know how >>>>>> we >>>>>> should commit the preflight modifications without "breaking" the 1.7 >>>>>> release. >>>>>> >>>>>> Here is 3 possibilities : >>>>>> >>>>>> 1 - Exclude the preflight module from the release and work with the >>>>>> current >>>>>> code without compatibility with the old version. >>>>>> >>>>>> Any suggestions how to do that easily? >>>>> >>>> >>>> >>>> I was thinking to comment the preflight declaration in the >>>> pdfbox-reactor >>>> pom file. >>>> Doing this, the source code will be present in the tagged version, but >>>> they >>>> will not have preflight jar in the repository with the version 1.7. >>>> >>>> It's may not be the best way to achieve that but it is probably the >>>> easiest >>>> way... >>>> >>>> >>>> 2 - Include the preflight module in the 1.7 release, the new >>>>> >>>>>> implementation >>>>>> will be create in new packages. They will have no more modifications >>>>>> of >>>>>> the >>>>>> old implementation that will be marked as deprecated. Expect bug fix >>>>>> nothing will be done on old version, only new implementation will be >>>>>> improved (new configuration capabilities, new validation format...). >>>>>> Old >>>>>> version will be definitely removed in a further release (1.8 or 2.0 ?) >>>>>> >>>>>> 3 - Include the preflight module unchanged and release it. The new >>>>>> validation tool will be done in a new module (Present only in the 2.0 >>>>>> branch ?). They will have no more modifications of the old module that >>>>>> will >>>>>> be marked as deprecated. Expect bug fix nothing will be done on old >>>>>> version. Only new module will evolve (new configuration capabilities, >>>>>> new >>>>>> validation format...). >>>>>> >>>>>> I don't like the idea of releasing code for the first time which is >>>>> already meant to be dead. >>>>> >>>>> >>>> >>>> What is your opinion about that ? >>>>> >>>>>> >>>>>> IMHO, as there wasn't any Apache release of preflight the cleanest >>>>> way >>>>> would be to replace the "old" implementation using the "new" one. But >>>>> there >>>>> are some questions: >>>>> >>>>> - Is the "new" implementation completed? If not, when do you expect to >>>>> be >>>>> ready? >>>>> >>>>> >>>> >>>> No, it isn't. Hopefully I will finish the refactoring at the end of June >>>> (but without guaranty), so it will be quite late for the 1.7 release. :( >>>> >>>> >>>> - Is the "new" implementation a full replacement of the old one ? >>>> >>>>> >>>>> >>>> >>>> No, I thought that around 50% of the code will be reused. >>>> >>>> >>>> >>>> Depending on your answers and other opinions we might postpone the >>>>> release >>>>> for a couple of weeks. >>>>> >>>>> >>>>> If you have any questions, do not hesitate. >>>>> >>>>>> >>>>>> Don't hesitate to answer fast ;-) >>>>> >>>>> >>>> One more time, I'm really sorry to delay the pdfbox release. >>>> >>>> >>>> BR, >>>>> >>>>>> >>>>>> Eric >>>>>> >>>>>> >>>>>> BR >>>>> Andreas Lehmkühler >>>>> >>>>> >>>> BR, >>>> Eric >>>> >>> >> > > -- > > Timo Boehme > OntoChem GmbH > H.-Damerow-Str. 4 > 06120 Halle/Saale > T: +49 345 4780474 > F: +49 345 4780471 > [email protected] > > ______________________________**______________________________**_________ > > OntoChem GmbH > Geschäftsführer: Dr. Lutz Weber > Sitz: Halle / Saale > Registergericht: Stendal > Registernummer: HRB 215461 > ______________________________**______________________________**_________ > >
