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 Re: Confirm the change set will be included in the first release.
Date Thu, 22 Sep 2011 18:57:26 GMT
Am 22.09.2011 19:17, schrieb Rob Weir:
> On Thu, Sep 22, 2011 at 1:05 PM, Svante Schubert
> <svante.schubert@gmail.com> wrote:
>> Am 21.09.2011 09:30, schrieb Devin Han:
>>> Hi all,
>>>
>>> As you know, most of migration work  has been completed except JIRA and IP
>>> clearance. I think it's time to discuss the change set will be included in
>>> the first release.
>>> We have had a agreement that there would no new feature included in this
>>> version. In my opinion, the content of the first release should contain:
>>> 1. Rename package name from "org.odftoolkit" to "org.apache";
>>> 2. Simple API and ODFDOM merge;
>>> 3. License update;
>>> 4. Code refactor, it's an opportunity to remove the deprecated method,
>>> change method name and clear the code. User has the biggest tolerance this
>>> time.
>>>
>>> Any comment?
>> I believe we all have agreed not to add new features to our first release.
>> The general question is, shall we minimize our changes for the first
>> release to get a release as soon as possible ready, which is basically
>> identical to the last one in ODF TOOLKIT, only in a different location
>> with our environment set-up and documented.
>> Or shall we do required major code changes as well, so the user will
>> have no larger problems after using that version.
>>
>> I would vote for release often and early and do two releases before
>> coming up with a feature release.
>> First do a more-or-less identical release of former ODF Toolkit and
>> second to the required changes.
>>
>> We might still want to adapt the license - to avoid any legal problems -
>> and the package names - to make obvious where the code comes from -, as
>> users might do package changes easily with a search & replace.
>> But I have no strong feelings on that.
>>
> We can't do any release until we've done the IP review, including
> updating the headers, the NOTICE file, etc.  I believe this is an
> Apache requirement.
>
> A good overview of the Apache requirements is here:
>
> http://incubator.apache.org/guides/releasemanagement.html
>
> I'd support the idea of making an Apache release of the code we have
> now, doing the work necessary to meet the Apache requirements, but not
> making any functional changes to the code.
>
> On the other hand, we're waiting for the Oracle SGA right now.  So I'm
> not sure we can make much progress on the header cleanup until we get
> that.  According to this page we are not supposed to change the
> headers until we have permission from the copyright owner:
>
> http://www.apache.org/legal/src-headers.html
>
> What we can do now, is make progress in areas like:
>
> 1) A script to build the combined release archives for the project
+1
>
> 2) Drafting combined release notes, or maybe a top level release note
> that points to component-specific release notes?
I would love to have an introduction of the overall purpose and the
modules we are offering. Like someone would have for an SDK...
Regarding the release notes, I like your idea of having one collected
summary and references to the detailed distinct release notes.
>
> 3) Maybe unified JavaDoc?
I really do like the easiness of the Simple API JavaDoc as there are so
little classes involved.
We should only give the user the complexity, he needs. Therefore I
prefer to have distinct APIs for the distinct modules.
>
> 4) Merge of ODFDOM and Simple API could also be done, I think.  Or
> next release.  I don't have strong preference.
Quoting you from above:
> "I'd support the idea of making an Apache release of the code we have
> now, doing the work necessary to meet the Apache requirements, but not
> making any functional changes to the code."
I would drop the Simple API / ODFDOM DOC merge for the first release.
Especially as we should keep Simple API as its own distinct bundle to
maintain the simplicity, as users might want to work solely with that
high level API.
I am curious how a merge might look like, does anyone of the former
Simple API team have suggestions?
>
> 5) We need to agree on an initial version number for the release.
> Apache ODF Toolkit version X.X ?
Currently every module ODF Validator, ODFDOM and Simple API has its own
version number. (Michael Brauer - the former project owner - had not
given a version number to the validator, but I added one with the recent
update).

The versions are now:
0.6.6. for Simple API
0.8.7 for ODFDOM and the validator.

Does it makes sense to give each module its version number and a
different one for the overall umbrella deliverable?
I think this make sense as if there are new tools in the future, they
might start with their own numbering and if a module was not change its
version will not be updated, otherwise confusing the user.

Therefore my suggestion is to keep the version numbers of all sub
projects and give the overall project the highest version number of all
for the start, 0.8.7.

- Svante



Mime
View raw message