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 <eric.leleu....@gmail.com> wrote: > Hi, > > 2012/5/22 Andreas Lehmkuehler <andr...@lehmi.de> > >> 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
