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 Sun, 25 Sep 2011 06:36:03 GMT
Am 23.09.2011 20:42, schrieb Michael Stahl:
> On 22.09.2011 20:57, Svante Schubert wrote:
>> 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:
>>> 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 validator already has a version number, currently 1.1.4:
>
> http://svn.apache.org/viewvc/incubator/odf/trunk/validator/src/main/java/org/odftoolkit/odfvalidator/Main.java?revision=1172466&view=markup#l41
Yes, thanks for the hint, only looked in to the Wiki and have overseen
the the private static field in Main.java and the runtime parameter.
We might want to set the version solely in the pom.xml, write it into
the manifest of the JAR and read it from the JAR via a Version helper
during run-time.
In other words similar as ODFDOM does it.
>
>> The versions are now:
>> 0.6.6. for Simple API
>> 0.8.7 for ODFDOM and the validator.
> so now the validator has two version numbers?
Currently yes, see above for solution and we might overtake the previous
number in the pom.xml
>
>> 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.
> a good strategy in principle, but how do you prevent ambiguities when the
> validator again reaches higher version numbers in the 1.x range that were
> already used previously?
Claro, therefore we keep the original number..
>
>> - Svante
> regards,
>  michael
>


Mime
View raw message