incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svante Schubert <svante.schub...@gmail.com>
Subject First release feature set (earlier -- Re: Merge of ODFDOM DOC package and Simple API)
Date Mon, 26 Sep 2011 12:50:32 GMT
Am 26.09.2011 08:30, schrieb Devin Han:
> 2011/9/23 Svante Schubert <svante.schubert@gmail.com>
>
>> Am 23.09.2011 05:27, schrieb Devin Han:
>>> 2011/9/23 Svante Schubert <svante.schubert@gmail.com>
>>>
>>>> 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:
> http://incubator.apache.org/odftoolkit/odfdom/ReleaseNotes.html.  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?
Svante


Mime
View raw message