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 >>> 2.7.0.1? >> >> 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 2.7.0.1, 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 > > Thorsten
