incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: First release feature set (earlier -- Re: Merge of ODFDOM DOC package and Simple API)
Date Mon, 26 Sep 2011 18:28:13 GMT
On Mon, Sep 26, 2011 at 8:50 AM, Svante Schubert
<> wrote:
> Am 26.09.2011 08:30, schrieb Devin Han:
>> 2011/9/23 Svante Schubert <>
>>> Am 23.09.2011 05:27, schrieb Devin Han:
>>>> 2011/9/23 Svante Schubert <>
>>>>> I agree with Devin to do the merge of Simple API and the ODFDOM Doc
>>>>> layer before the next feature release.
>>>>> Thanks for your support ;)
>>>> At least, we can remove the ODFDOM Doc layer.
>>>> Lots of bugs in it, user should drop it and turn to Simple API.
>>> Careful with the claim of bugs, it might backfire as we wrote that code
>>> together. ;)
>> Doesn't matter, you can see how many bugs are fixed and how many new
>> features are added after Simple splited from ODFDOM ;)
>>> Nevertheless I agree to favor Simple API.
>>> It just took a little longer to understand that with 'merging with DOC
>>> layer'  you meant 'deleting the DOC layer'.
>>> The DOC layer is a superset in regard of functionality and especially
>>> the tests should be reviewed if they might help us to archive a better
>>> coverage.
>>> In our first no-functionality-change release we should keep the doc
>>> layer and mark/document that layer as deprecated.
>> I prefer to give user a more clean library. No deprecated, just removed. We
>> can supply a document to explain it, just as we have done in ODFDOM, see:
>>  What's a
>> big change, isn't it?  For these changes, I insist that we do it in the
>> start.
>> Users have the most tolerance for the first release.
>> On the other hand, I did the split work between ODFDOM and Simple API. I
>> know it's easy to merge them. Why not we do it now?
>> Apache is a new start for us. We shouldn't fear change, but should fear we
>> can't supply a clean, stable and easy used tool to users!  For this, we need
>> a clean and stable code base!
>> Anyway, ODFDOM Doc Layer must be remvoed and replaced with Simple API in the
>> first release.
> It seems to me have discussed the first feature set already in several
> other mail threads.
> Let me summarize and come up with a suggestion.
> We need to pass anyway a milestone where we have all documentation ready
> and check to deliver a release. Most of us like the idea to release
> early and often.
> You want to do a release only if the structure is stable.
> I suggest that we do only a SNAPSHOT release first. Keeping all the
> sources from the former ODF Toolkit and doing no functionality changes.
> In the following we refactor what we can to stabilize the structure of
> the sources. For instance, split-up an own package JAR.
> After that we might focus on a feature release, e.g. ODF
> encryption/signature.
> Does this suit everyone?

A release is a release, whatever we call it.  A release does not happen until:

1) We've completed the IP review

2) We have a script that builds the release archives

3) We vote to approve having a release

4) the Incubator PMC votes to approve the release

I may be missing some other requirements in there, but that is the
general outline.

For Step 1 we're waiting on the Oracle SGA for further progress.  I've
done all I can do from the IBM perspective with the IBM-contributed

Step 2 is the main technical task remaining for a minimal release.  So
I'd recommend that as our next task.  Once we have that then we can
branch for stabilization.  Or branch for new work.  I'm fine with
either approach.  But the idea is that we allow work to continue on
features for the next release while we wait for the Oracle SGA.  Once
we have that SGA we can complete the IP review process and release
from the branch (or trunk) depending on our approach.  If we find that
the SGA takes more than a couple of weeks, we might then discuss
further and agree to merge in work from the feature branch into the
release.  Or not.  But we don't need to decide that right now.  We
just need to agree on when we branch.  I propose we do that after we
have a consolidated build script.


> Svante

View raw message