On 15/11/2019 09:49, Marco Neumann wrote:
I believe future versions of Jena need to be a bit bolder, this while
maintaining basic API features and design choices for compatibility in a
maintenance release.
Agreed - there should be a system which is production-stable, certainly
covering up to Fuseki+text with extension points.
Then there are evolving modules.
For example, SPARQL 1.2 does not destabilize SPARQL 1.1 - that may mean
1.2 is separate and optionally replaces 1.1. When some 1.2 features are
considered stable, they move to core-ARQ.
And some things like first steps in concurrency for ARQ don't need to be
in release.
Jena 4 might be a good candidate for such a LTS
maintenance release while Jena 5 should take a more ambitious approach and
innovate where it hasn't made inroads in the technical community yet.
Jena3 is LTS in practice.
Given we have non-dedicated resources, I don't think it is helpful to
ourselves to set up some grand long term roadmap that we can't
realistically achieve. What will happen is that progress will be
demotivating slow when measured against the ultimate goals.
If more people become active contributors or some of us can get
resourcing, then that can change.
Andy
(SPARQL 1.2, RDF 2, parallelization/concurrency, improved scripting
support, web focus, UI, integration with other projects etc). I believe
last time we have seen such transformative change to Jena was for releases
2.7+ and the migration of the project to the Apache software foundation
almost 10 years ago.
And IMO an area that needs closer attention as well is documentation,
education and outreach. I am not sure where we currently stand in
regards to developer adoption, downloads and deployments etc but it would
be useful to gauge this type of information more systematically and more
regularly for project reviews.
Marco
On Wed, Nov 13, 2019 at 7:18 PM Andy Seaborne <a...@apache.org> wrote:
I'd like to start a discussion on where the project might go longer term.
This can be specific areas, overall design, about project processes,
anything.
If we are going to do a major change, Jena4, what preparation for that
can be done? (e.g. deprecation and signalling in Jena3, before the
change happens).
Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4
need not be that big - we can have Jena5 etc.
I'll put some technical points in a separate email.
I would put on the list:
* How has the world changed? What should the project produce?
* Target audience: for developers of Jena, while Jena3 is for users.
* Target: Java14, JPMS.
* Clear-up not easily done with perfect compatibility.
* Simpler. There are APIs and packages entangled due to history.
To the lurkers :-)
Feedback and specific feature requests are welcome. But before you "go
shopping", you may wish to factor in that every feature needs effort to
do it. The better place to be is that an application can get what it
needs to do, not whether the Jena system has every feature built-in.
Andy
