I am amazed how often I am seeing a desire to change more than one thing at once in order to achieve some immediate end. I am much more cautious than that. My normal inclination is to see how to minimize the amount of change done at any one time. That way, any failure is easy to isolate; changes can be removed and redone easily.
I also worry about breaking in-bound dependencies that others have and it is not known what they are. I therefore urge you to consider retiring the DOC layer, but not removing it from the code base. Someone may come looking for it. It might even be something someone wants to start from in their own work. There is no way of knowing. Whether it is not included in a release and all dependencies on it are removed from a release is a different matter. I am unclear how that works at Apache. As long as your code base is clean (satisfying Apache requirements), perhaps it doesn't matter that there are portions of the code base that releases no longer depend upon and do not include. - Dennis OT: Ah, now I see where things blur together in message threads If I were to do in-line comments in this message, it would not be clear what I add and what are the in-line comments from Devin. That is because there are at least three approaches to enclosure-quoting and markup involved here. Wonderful: an over-constrained problem. -----Original Message----- From: Devin Han [mailto:[email protected]] Sent: Sunday, September 25, 2011 23:30 To: [email protected] Subject: Re: Merge of ODFDOM DOC package and Simple API 2011/9/23 Svante Schubert <[email protected]> [ ... ] > 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. [ ... ]
