Makes sense to me, I'm only using TDB (I think I only ever used SDB following
an old tutorial for some inference or another tool that had used SDB, long time
ago). +1
On Thursday, 28 January 2021, 10:08:39 am NZDT, Andy Seaborne
<a...@apache.org> wrote:
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
>>>
>>
