I checked with with VIVO and they are migtrating to TDB as the primary
store.
https://jira.lyrasis.org/browse/VIVO-1741
If we retire SDB, they will do the same on their end.
And anyway we can put it back again easily enough.
The IRI changes (which include API changes) cause a few changes in SDB
because SDB is old and uses what are nowadays really non-public APIs.
It's easy to fix up, so if we archive just before the next release it'll
practical that anyone missing it can a version build immediately, not
wait for a release cycle.
Andy
On 25/01/2021 11:15, Andy Seaborne wrote:
It is semi-retired saying "not suitable for new work".
There's an open source project using it (vivoweb); they plan to move off
it. Someone showed up awhile ago (about a year ago). So while they are
migrating (and it isn't instant for them and their downstream), I'm
happy to personally keep it alive for now for small things. I had a call
with them back then and they know the situation.
If the unlikely occurs and some major change is needed, it will get
dropped from the build. I like this division of modules into "essential"
and "droppable".
Given SDB is not tightly integrated in with other parts of Jena (due to
age), the mostly likely threat to it is a security risk. I would not
want a release have a CVE against it just because of SDB.
Then definitely; less is more.
Andy
On 23/01/2021 01:47, aj...@apache.org wrote:
Is SDB perhaps another candidate for retirement?
Adam
On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne <a...@apache.org> wrote:
On 01/01/2021 12:13, Andy Seaborne wrote:
Should we switch to Java11?
Proposal:
1/ Ask on users@ -- what we need is "new information" such as "I am
blocked from updating Java because ...", not "I haven't got round to
it".
2/ Switch to Java11 for the next release but not make so many changes
that we can't easily go back to Java8.
Andy
The discussion on users@
https://lists.apache.org/thread.html/re6bd2d266343a5dffc2b811df2ed63caea07196db42bb929a6b2fb7d%40%3Cusers.jena.apache.org%3E
Points:
* bump to Jena4.
* request to keep a parallel 3.x branch (nice if resourced only if
resourced)
If Jena4, then are there any things we can do which won't significant
impact the timescale - we can take longer of course but I think any
major work item that would need several additional months, and all the
risk of that slipping :-), really must be important.
1/ Mass removal of deprecated - a lot has been deprecated for many
versions so removing it a 4.x seems reasonable. I hope people have been
taking note but code can always return if necessary.
2/ Retire modules or remove code we do not want to migrate to Jena4,
especially as we can still include it again later if there is
unanticipated user demand. Again, a major version jump is a time to be
bold(er); all code has cost.
jena-text-es is a candidate from my point of view. No one is maintaining
it and it is complicated to setup and support.
Andy