incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Möller <>
Subject Re: Jena release : suggested approach
Date Wed, 30 Nov 2011 16:51:06 GMT

Am 30.11.2011 um 17:45 schrieb Thorsten Möller:

> Am 30.11.2011 um 17:26 schrieb Paolo Castagna:
>> Thorsten Möller wrote:
>>> Am 30.11.2011 um 10:39 schrieb Andy Seaborne:
>>>> == Version number
>>>> I think it's worth bumping the minor version number on ARQ and Jena - the
jar files have changed name format; the maven artifacts have different names, ARQ is SPARQL
1.1 (query, update) complete.
>>>> JenaTop 0
>>>> IRI 0.9.0
>>>> Jena 2.7.0
>>>> ARQ 2.9.0
>>>> LARQ?
>>>> Download 2.7.0 (in line with Jena core)
>>> Does it mean version numbers of the download and Jena-core are kept in line just
for this release or also for future releases? What if you want to release a new download (because
of a critical bug in a non Jena-core module) while the version of Jena-core has not changed
- fourth level
>> Hi Thorsten,
>> I am not sure I completely understand your question.
>> But, let's say a critical bug is found in jena-core 2.7.0.
> That's the innocuous case. Suppose the initial versions are Jena-Core 2.7.0 and 2.9.0
for ARQ. Then a critical bug is found and fixed in ARQ, a new release of ARQ is made having
a new version number, say 2.9.0->2.9.1, and you want to provide a new/updated download.
Then you either have the option of increasing the version of the download, say 2.7.0->2.7.1,
which results in tying it apart from Jena core. Or you introduce a fourth level for the download, thereby keeping the first three levels in line with Jena core.

Well, there is also a third option of appending a release date (or build number) after the
version number, similar to how it is done in the Eclipse community (e.g., 4.1.1-201109121510).


> Thorsten

View raw message