incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yegor Kozlov <yegor.koz...@dinom.ru>
Subject Re: Merge of ODFDOM DOC package and Simple API
Date Fri, 30 Sep 2011 12:38:38 GMT
On Fri, Sep 30, 2011 at 4:29 PM, Rob Weir <robweir@apache.org> wrote:
> On Fri, Sep 30, 2011 at 4:48 AM, Devin Han <devinhan@apache.org> 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 <devinhan@apache.org>
>>
>>> +1
>>> OK, I agree for a snapshot release with no functional code change.
>>>
>>> 2011/9/29 Dennis E. Hamilton <dennis.hamilton@acm.org>
>>>
>>> +1 (non-binding [;<).
>>>>
>>>> -----Original Message-----
>>>> From: Svante Schubert [mailto:svante.schubert@gmail.com]
>>>> Sent: Wednesday, September 28, 2011 15:22
>>>> To: odf-dev@incubator.apache.org
>>>> 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
>>
>

Mime
View raw message