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. > 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 >> >
