On Fri, Sep 30, 2011 at 8:38 AM, Yegor Kozlov <[email protected]> wrote: > On Fri, Sep 30, 2011 at 4:29 PM, Rob Weir <[email protected]> wrote: >> On Fri, Sep 30, 2011 at 4:48 AM, Devin Han <[email protected]> wrote: >>> I try to add @Deprecated Annotation to the ODFDOM Doc Layer classes. The >>> question is that we will just re-release ODFDOM 0.8.7. If I add the >>> annotation based on the newest trunk that means we will release a new >>> version different from ODFDOM 0.8.7 and the adoption work must do for >>> Simple API caused by this issue: >>> https://issues.apache.org/jira/browse/ODFTOOLKIT-49 (ODFDOM has moved the >>> style access methods from the package layer OdfFileDom to OdfStylesDom and >>> automatic style access to OdfStylesDom & OdfContentDom after ODFDOM 0.8.7) >>> which I have mentioned in other thread. >>> >>> What should we do? >>> >> >> I think we want to start working like one project, with one toolkit, >> with one build. >> >> This has some consequences: >> >> 1) We need to have a top-level builds script or POM that builds the >> entire release from the trunk. >> >> 2) Simple API, Validator and XSLT Runner should be compiling against >> the current trunk version of ODFDOM. No more using an old 0.8.7 JAR. >> >> 3) If you make a change in one component that breaks another >> component, then you've broken the build. We one project, with one >> toolkit, with one build. >> >> 4) To avoid breaking the build, we need to be compiling and running >> the unit tests on all components, not just the one we are currently >> working on. If the code you change in ODFDOM breaks the Validator, >> then you should not check in your changes until you've fixed. Or, for >> larger changes, that break a lot of code, we should discuss on odf-dev >> list first, and coordinate on how we work together to update the other >> components. >> >> The current build breakage occurred before we came to Apache, before >> we started thinking of "one project, with one toolkit, with one >> build". No one is too blame. It was acceptable before. But now it >> is a problem. >> >> What can we do? >> >> 1) What is the scope of the breakage? Is it just Simple API? Or do >> any of the other dependent components fail to compile against the >> trunk ODFDOM? >> > > I plan to play with the code on weekend will give my feedback after that. >
Thanks! No rush. It is a Chinese national holiday next week, so Daisy and Devin will be out. I'm on vacation next week. And Svante said he has a priority report he is working on for the OASIS ODF Technical Committee. So it sounds like a quiet week for this project next week. -Rob >> 2) What is the impact on the user's code? Will the ODFDOM changes break >> them? >> >> 3) How much effort will it be to update the Simple API so it works >> with trunk version of ODFDOM? >> > > The breakage of the Simple API becomes a release blocker. I'm for > fixing ODFDOM , but if it is hard then revert is OK too. > > Yegor > >> If it is possible to update the Simple API, I think that is the best >> way forward. The alternative would be to revert ODFDOM back to before >> these changes were made. >> >> -Rob >> >> >> >> I think adding @deprecated is best when we can point the user to an >> alternative function to use. Otherwise it is not very useful. >> >> >>> 2011/9/29 Devin Han <[email protected]> >>> >>>> +1 >>>> OK, I agree for a snapshot release with no functional code change. >>>> >>>> 2011/9/29 Dennis E. Hamilton <[email protected]> >>>> >>>> +1 (non-binding [;<). >>>>> >>>>> -----Original Message----- >>>>> From: Svante Schubert [mailto:[email protected]] >>>>> Sent: Wednesday, September 28, 2011 15:22 >>>>> To: [email protected] >>>>> Subject: Re: Merge of ODFDOM DOC package and Simple API >>>>> >>>>> Am 28.09.2011 17:55, schrieb Rob Weir: >>>>> [ ... ] >>>>> > Could we mark the DOC API's as "deprecated" in our initial release, >>>>> > and point to the replacements in the Simple API? We could do that in >>>>> > the JavaDoc. That will give users the opportunity to migrate, but we >>>>> > don't break their code immediately. Then we can remove the DOC API in >>>>> > a future release. >>>>> > >>>>> > Would that work? >>>>> > >>>>> +1 >>>>> >>>>> We might make the initial release a no functional code change snapshot >>>>> release. >>>>> For us to proof we are able to deliver and sign the users we have >>>>> continued here at Apache. >>>>> >>>>> >>>> >>>> >>>> -- >>>> -Devin >>>> >>> >>> >>> >>> -- >>> -Devin >>> >> >
