Jena on Cassandra works.  I still think we need to think about how to
handle distributed data stores so they appear as a single data store to the
application.  (e.g. If someone adds a triple to the store then other
clients of the store won't be notified one the listener interface).

I suspect the same issue exists in SDB when the DB is used by multiple
clients.

I am not certain how to proceed.  I think we should also discuss how we
want to add additional components.  It seems like the core product should
be left as it is (or perhaps remove SDB) and additional components made
available.  So SDB and Jena on Cassandra would be additional components to
download and plug into a system.

In any case do not hold up release for Jena on Cassandra.


Claude

On Wed, Apr 5, 2017 at 6:32 PM, Andy Seaborne <[email protected]> wrote:

> I'd like to leave open the possibility of changing RIOT details.  I've
> held off API changes as far as possible and flagged things by deprecation.
>
> (these are to low level extension points I have no direct evidence anyone
> uses except Jena itself, not main public APIs)
>
> Expanding the point to general from 3.4.0/3.3.1 specifica:
>
> If we have a 3.x.0/clocktick style, maybe we can better evolve more easily
> - removing deprecations for example.
>
> Our general level of stability/compatibility would be just as strong as
> has been.
>
> So far:
> 3.0.0, 3.0.1, 3.1.0, 3.1.1, 3.2.0, 3.3.0
> 2.11 even got to 2.11.2.
>
> We can only do 3.x.1 if everything is 3.x.1.
>
> I'd like to not have multiple development branches just because we can. If
> there is a reason, I'm cool with it but it makes work keeping them in step
> and risks mistakes.
>
> This is, to me, about finding the balance between evolution and stability
> - not making major changes. Semantic versioning on a multi-unit release
> means that increments are going to be rare.
>
> Not promises incremental-only gives each of us more freedom.  We can at
> the last minute decide the actual version.
>
> There are other things we can do - a division into "core" (e.g. main)
> modules and "additional".  Even two separate releases to decouple changes.
> Making changes deep down in RIOT to TriX affected Elephas. That is a
> somewhat tight binding; TriX is supported "because we can :-)" rather than
> an important format.
>
>     Andy
>
>
> On 05/04/17 15:35, A. Soroka wrote:
>
>> Right.
>>
>> I'd like to retrench a bit and do a 3.3.1 next. I should have some time
>> in the next month or three to do some Javadocs and so forth, and I think
>> that might be valuable. OTOH, if there are grander ideas ready to move
>> forward (e.g. Jena-over-Cassandra) I'm in no way opposed.
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>> On Apr 5, 2017, at 10:33 AM, Andy Seaborne <[email protected]> wrote:
>>>
>>>
>>>
>>> On 05/04/17 15:27, A. Soroka wrote:
>>>
>>>> What with the changes in the text indexing systems, I think 3.3.0 makes
>>>> sense (we talked about this right?). Or were you meaning to consider
>>>> between 3.3.1 and 3.4.0?
>>>>
>>>
>>> 3.4.0 or 3.3.1.
>>>
>>> We are somewhat committed to 3.3.0 by now :-)
>>>
>>>    Andy
>>>
>>>
>>>> ---
>>>> A. Soroka
>>>> The University of Virginia Library
>>>>
>>>> On Apr 5, 2017, at 10:25 AM, Andy Seaborne <[email protected]> wrote:
>>>>>
>>>>> How are things looking for a 3.3.0 release?
>>>>>
>>>>> A lot of good stuff has happened and the clock tick is approaching.
>>>>>
>>>>> I'm offering to either be the release manager to help someone with it.
>>>>>
>>>>> What will be the next version number?
>>>>>
>>>>>         Andy
>>>>>
>>>>> Thoughts:
>>>>>
>>>>> 1/ Our regular releases are 3.x.0 and we reserve 3.x.1/2/3 for
>>>>> out of cycle releases.
>>>>>
>>>>> So next release is 3.4.0.
>>>>>
>>>>> 2/ Harmonise the version numbers. 3.x.0 for everything.  Don't worry
>>>>> that we then have "Fuseki1 3.x.0" and "Fuseki2 3.x.0".
>>>>>
>>>>> This may remove a small point of friction in the release eventually
>>>>> (not this release) which is having to not reply repeated to the
>>>>> before/after version questions from the maven release plugin.
>>>>>
>>>>> The last time I tried that (elsewhere) maven failed to update to the
>>>>> next version properly and I ended up with a broken mess which is why I'm
>>>>> not suggesting this second step this late in the cycle.
>>>>>
>>>>
>>>>
>>


-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Reply via email to