Paulo, thanks. The pom.xml information is certainly useful as it proves how the tests were run. In most cases this will be enough. However, problems start happening when a later component (e.g. LARQ) has been tested with later snapshots than the current release. I think it is important that all components can run with a release for the other components (perhaps you already guarantee this?) Now, even if this is the case, it may still be tricky because approvals or adoptions by jena consumers (like myself) are done on a specific version release and updating it quickly because one component was not released before may be hard or even impossible.
So, from a consumer point of view, you ideally release everything together :-). It would also get rid of the various unaligned version numbers of different components, which are very confusing. Ideally, I just say "Jena 2.7.1" (and includes IRI 2.7.1, ARQ 2.7.1, TDB 2.7.1, etc.) Simon From: Paolo Castagna <[email protected]> To: [email protected] Date: 05/25/2012 12:59 PM Subject: Re: Next apache-jena release Simon Helsen wrote: > 4) LARQ: so far, we have not been using it, but we are thinking of > starting with that, so having it released with 2.7.1 would be nice. If > this does not happen, then, it would help if there is a clear indication > with what release a given component would be compatible (that request > would apply to any component which is not released with the "main" pack Hi Simon, knowing which module is 'compatible' with other modules is easily done by inspecting the pom.xml of a module. For example, if we look at LARQ 1.0.0-incubating's pom.xml file you can see that it depends on: - Lucene 3.5.0 - ARQ 2.9.0-incubating - TDB 0.9.0-incubating (for the tests only) Same for other modules. Answering questions such as would it work with any Lucene 3.x? Or, would it work with any ARQ 2.9.x or any TDB 0.9.x? ... is another, non trivial, thing. (Probably it is this you were referring to) Some projects have conventions on increments of their minor version numbers (and they promise that minor increments leads to drop in replacements fully backward compatible). It also is not uncommon that bug fix releases [x].[y].[z + 1] are just that and fully backward compatible. I don't expect any 'big' and/or incompatible changes in LARQ 1.x. My goal for LARQ is to keep its dependencies updated with changes in ARQ and TDB as well as upgrade Lucene dependency as soon as a new Lucene 3.x release is out. Longer term, I want to fix JENA-164 first, probably do nothing about JENA-242 and finally see if I find the time to actually work on JENA-17 for LARQ 2.x But, listening feedback (and complaints) from users is also what drives things. For example, Lucene analyzers should probably be configurable in any serious scenario, we recently have seen an example of this on the users mailing list. However, the more we expose Lucene features, the more we get tied to it and there might be issues in future when we want to allow using other systems such as Solr, Elastic Search (although they are all based on Lucene ;-)). Paolo [1] http://repo1.maven.org/maven2/org/apache/jena/jena-larq/1.0.0-incubating/jena-larq-1.0.0-incubating.pom
