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
