You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2017/04/05 14:25:29 UTC
Release 3.3.0?
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.
Re: Release 3.3.0?
Posted by Andy Seaborne <an...@apache.org>.
On 07/04/17 11:30, Osma Suominen wrote:
> 06.04.2017, 19:21, Andy Seaborne kirjoitti:
>
>> Osma,
>>
>> How are thing looking from your perspective?
>
> Looking pretty good for a release, however, the documentation updates
> are not yet done. I was hoping Anuj would do an update but he hasn't
> responded...
>
>> The main focus of the 3.3.0 release is the lucene/solr/ElasticSearch
>> changes. We should set the timeline based on this work.
>>
>> PR#227 is open but the comments seem to imply the changes are in.
>
> It can be closed, I just don't have the rights to do that. I put in a
> comment stating the same.
Not through the GH UI but we want to put it into the ASF copy which gets
mirrored to GH, not update the GH mirror and flow back to ASF..
Any commit on the ASF codebase with the magic phrase will do. It does
not have to the only comment or indeed on the first line. As the phrase
is quite bland, it's a bit scare really.
It can be done after all the work with:
git commit --allow-empty -m "JENA-1305. This closes #227."
Normally, this can be done within the workflow of pulling from GH
git pull github pull/227/head --no-ff
... editor pops up with the merge message ...
... add a line saying ....
"JENA-1305. This closes #227."
...
where:
[remote "github"]
url = git@github.com:apache/jena.git
fetch = +refs/heads/*:refs/remotes/github/*
this ought to be written down on
https://cwiki.apache.org/confluence/display/JENA/Processes
now that we use this if anyone has a moment to start some words.
The GH flow is working well and I think it encourages contributions. The
fact we use it as well as contributors outside the PMC is important.
>
>> JENA-1305 mentions documentation.
>
> Right. That should be done by the time of release, or soon after. I'll
> make sure that it gets done one way or other.
>
>> There is also JENA-1313 - how do feel about before/after 3.3.0 on this?
>
> No reason to delay the release because of a proposed new feature for
> which we don't yet have any code.
OK.
>
>> My preference is "release early, release often" not make JENA-1313 a
>> precondition unless it is nearly ready - the lucene switch and
>> ElasticSearch are valuable to get out.
>
> Agree.
>
> -Osma
>
Thanks for the update ... onward to 3.3.0.
Andy
Re: Release 3.3.0?
Posted by Osma Suominen <os...@helsinki.fi>.
06.04.2017, 19:21, Andy Seaborne kirjoitti:
> Osma,
>
> How are thing looking from your perspective?
Looking pretty good for a release, however, the documentation updates
are not yet done. I was hoping Anuj would do an update but he hasn't
responded...
> The main focus of the 3.3.0 release is the lucene/solr/ElasticSearch
> changes. We should set the timeline based on this work.
>
> PR#227 is open but the comments seem to imply the changes are in.
It can be closed, I just don't have the rights to do that. I put in a
comment stating the same.
> JENA-1305 mentions documentation.
Right. That should be done by the time of release, or soon after. I'll
make sure that it gets done one way or other.
> There is also JENA-1313 - how do feel about before/after 3.3.0 on this?
No reason to delay the release because of a proposed new feature for
which we don't yet have any code.
> My preference is "release early, release often" not make JENA-1313 a
> precondition unless it is nearly ready - the lucene switch and
> ElasticSearch are valuable to get out.
Agree.
-Osma
--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: Release 3.3.0?
Posted by Andy Seaborne <an...@apache.org>.
I am going by the state of JIRA and PRs to get a sense of what is ready
so please mark "resolved" any JIRA are done even if waiting for a
response from any OP. JIRA can be reopened. OP's can't always find
time at short notice.
Osma,
How are thing looking from your perspective?
The main focus of the 3.3.0 release is the lucene/solr/ElasticSearch
changes. We should set the timeline based on this work.
PR#227 is open but the comments seem to imply the changes are in.
JENA-1305 mentions documentation.
There is also JENA-1313 - how do feel about before/after 3.3.0 on this?
My preference is "release early, release often" not make JENA-1313 a
precondition unless it is nearly ready - the lucene switch and
ElasticSearch are valuable to get out.
Andy
On 05/04/17 15:25, Andy Seaborne 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.
Re: Release 3.3.0?
Posted by Andy Seaborne <an...@apache.org>.
On 05/04/17 21:54, Claude Warren wrote:
> 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).
The graph event handler contract does not work outside a single JVM.
For example, the event is dispatched and processed before the Graph.add
returns. Bad threading contract. Not viable in a distributed situation
(too many events, wrong timing) even without Cassandras eventual
consistency.
RDF Delta is an approach at addressing this
* Larger granularity (the transaction)
* Responsibility moves to the watchers who controls when change handling
happens
How are you dealing with the eventual consistency generally?
Andy
Re: Release 3.3.0?
Posted by Claude Warren <cl...@xenei.com>.
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 <an...@apache.org> 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 <an...@apache.org> 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 <an...@apache.org> 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
Re: Release 3.3.0?
Posted by "A. Soroka" <aj...@virginia.edu>.
Then I'm not quite sure what you are proposing, Andy... Are you suggesting that we have intermediate (< 6 month) releases which are not strictly bug fix releases? When you say "...those have to wait until a 6 month step..." is there something that is problematic about that that we could improve with a different release pattern? Or should they just wait for a 6-month step like other changes?
---
A. Soroka
The University of Virginia Library
> On Apr 6, 2017, at 11:42 AM, Andy Seaborne <an...@apache.org> wrote:
>
> tick-tock presumes people can plan their time ahead. I don't have that much control over when I can find time to make minor version-class changes so a tick-tock policy is another gating criteria and I'm guessing others face that too. It is a 6 month release cycle.
>
> Here, I've said I have some changes I want to get in which are, strictly, not for a bug fix release. Either those have to wait until a 6 month step, or make 3.3.0 wait longer (but I can't promise when they will be done) or deviate from a strict bug fix release.
>
> TDB2 can start to go in - I don't want that gated by a tick-tock but I can't promise in advance when it will get done.
>
> Andy
>
> On 06/04/17 16:12, A. Soroka wrote:
>> I'd like a tick-tock rhythm. I think that micro release is actually pretty important for getting small things right over time. It also helps with deprecations.
>>
>> The question of core and outside-the-core is a big one. I agree with Claude that "tightening" the core would be good, but I have a longer list of things that could be moved outside the core, e.g. a loosely-coupled Elephas.
>>
>> Maybe we can work on some coupling-loosening moves for the next minor release?
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>>> On Apr 5, 2017, at 1:32 PM, Andy Seaborne <an...@apache.org> 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 <an...@apache.org> 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 <an...@apache.org> 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.
>>>>>>
>>>>
>>
Re: Release 3.3.0?
Posted by Andy Seaborne <an...@apache.org>.
tick-tock presumes people can plan their time ahead. I don't have that
much control over when I can find time to make minor version-class
changes so a tick-tock policy is another gating criteria and I'm
guessing others face that too. It is a 6 month release cycle.
Here, I've said I have some changes I want to get in which are,
strictly, not for a bug fix release. Either those have to wait until a
6 month step, or make 3.3.0 wait longer (but I can't promise when they
will be done) or deviate from a strict bug fix release.
TDB2 can start to go in - I don't want that gated by a tick-tock but I
can't promise in advance when it will get done.
Andy
On 06/04/17 16:12, A. Soroka wrote:
> I'd like a tick-tock rhythm. I think that micro release is actually pretty important for getting small things right over time. It also helps with deprecations.
>
> The question of core and outside-the-core is a big one. I agree with Claude that "tightening" the core would be good, but I have a longer list of things that could be moved outside the core, e.g. a loosely-coupled Elephas.
>
> Maybe we can work on some coupling-loosening moves for the next minor release?
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Apr 5, 2017, at 1:32 PM, Andy Seaborne <an...@apache.org> 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 <an...@apache.org> 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 <an...@apache.org> 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.
>>>>>
>>>
>
Re: Release 3.3.0?
Posted by "A. Soroka" <aj...@virginia.edu>.
I'd like a tick-tock rhythm. I think that micro release is actually pretty important for getting small things right over time. It also helps with deprecations.
The question of core and outside-the-core is a big one. I agree with Claude that "tightening" the core would be good, but I have a longer list of things that could be moved outside the core, e.g. a loosely-coupled Elephas.
Maybe we can work on some coupling-loosening moves for the next minor release?
---
A. Soroka
The University of Virginia Library
> On Apr 5, 2017, at 1:32 PM, Andy Seaborne <an...@apache.org> 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 <an...@apache.org> 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 <an...@apache.org> 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.
>>>>
>>
Re: Release 3.3.0?
Posted by "A. Soroka" <aj...@virginia.edu>.
Urg! Urp! That was a typo-- I meant 3 months, as per previous discussion. Sorry! Trying to do too many things at once on a Friday.
---
A. Soroka
The University of Virginia Library
> On Apr 7, 2017, at 12:17 PM, Andy Seaborne <an...@apache.org> wrote:
>
> On 07/04/17 14:52, A. Soroka wrote:
>> I'm fine with trying for regular x.x.0 releases, but I would add two provisos:
>>
>> 1) We should have a calendar as well, particularly while we have a single codebase with two sync'd release products. In other words, we should do a release when either enough development has accumulated to justify a minor release or six months have passed. Otherwise we are waiting for arbitrary unscheduled work to complete to be able to release.
>
> Previously, we agreed a release every 3 months (kind unspecified), having moved from every 6 months.
>
> How about aim for a release every 3 months, with the option to decide to stretch that out if there isn't enough activity to make it worthwhile.
>
> (If 3 months is a bit of a stretch, 4 months.)
>
> Of course, a release can happen at any time in a "as needed, as resourced" basis.
Re: Release 3.3.0?
Posted by oc...@gmail.com.
I have no immediate objections. I'm going to be traveling a bit, but I
will try to take a look at those PRs in the next few days. I hope
someone beats me to them. If not, since Osma and I are traveling to the
same place, I will make him review them too! :grin:
ajs6f
Andy Seaborne wrote:
>
>
>
> On 07/04/17 14:52, A. Soroka wrote:
>>> Lastly, if no one else (modulo Andy) is interested, and if Andy would
>>> rather not, I will do the 3.3.0 release. But having done the last one,
>>> let me encourage any committers who haven't released to think about
>>> doing it. It wasn't difficult and I got to learn a good bit about
>>> Apache release mechanics quickly.
>
> On 07/04/17 17:17, Andy Seaborne wrote:
>>
>> Thank you.
>>
>> Andy
>
> There are some PR's I'd like to get into 3.3.0:
>
> PR#243
> JENA-1324: Check for spaces in URIs (if RDF 1.1)
>
> PR#242
> JENA-1323: RDFWriter
>
> PR#239
> JENA-1320: Cancel during sort.
>
> (modulo whatever Chris has done - if they are just tests, we should be
> good here but I see different changes in src/main)
>
> 1/ Dear RM - is that OK?
> 2/ Please could people review and approve them (there is nothing
> dangerous - honest!)
>
> Andy
Re: Release 3.3.0?
Posted by Andy Seaborne <an...@apache.org>.
On 07/04/17 14:52, A. Soroka wrote:
>> Lastly, if no one else (modulo Andy) is interested, and if Andy would
>> rather not, I will do the 3.3.0 release. But having done the last one,
>> let me encourage any committers who haven't released to think about
>> doing it. It wasn't difficult and I got to learn a good bit about
>> Apache release mechanics quickly.
On 07/04/17 17:17, Andy Seaborne wrote:
>
> Thank you.
>
> Andy
There are some PR's I'd like to get into 3.3.0:
PR#243
JENA-1324: Check for spaces in URIs (if RDF 1.1)
PR#242
JENA-1323: RDFWriter
PR#239
JENA-1320: Cancel during sort.
(modulo whatever Chris has done - if they are just tests, we should be
good here but I see different changes in src/main)
1/ Dear RM - is that OK?
2/ Please could people review and approve them (there is nothing
dangerous - honest!)
Andy
Re: Release 3.3.0?
Posted by Andy Seaborne <an...@apache.org>.
On 07/04/17 14:52, A. Soroka wrote:
> I'm fine with trying for regular x.x.0 releases, but I would add two provisos:
>
> 1) We should have a calendar as well, particularly while we have a single codebase with two sync'd release products. In other words, we should do a release when either enough development has accumulated to justify a minor release or six months have passed. Otherwise we are waiting for arbitrary unscheduled work to complete to be able to release.
Previously, we agreed a release every 3 months (kind unspecified),
having moved from every 6 months.
How about aim for a release every 3 months, with the option to decide to
stretch that out if there isn't enough activity to make it worthwhile.
(If 3 months is a bit of a stretch, 4 months.)
Of course, a release can happen at any time in a "as needed, as
resourced" basis.
>
> 2) We need to develop some kind of strategy for maintaining a core and "exterior" modules. We've already begun those discussions and I don't think anyone is opposed to this. Having a large codebase completely locked together is not a good stance for flexibility or being able to do releases.
>
> Lastly, if no one else (modulo Andy) is interested, and if Andy would rather not, I will do the 3.3.0 release. But having done the last one, let me encourage any committers who haven't released to think about doing it. It wasn't difficult and I got to learn a good bit about Apache release mechanics quickly.
Thank you.
Andy
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Apr 7, 2017, at 9:38 AM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>>
>> A big +1 to the proposed strategy
>>
>> Having more regular releases with whatever is ready is preferable to holding back work for the right release
>>
>> Rob
>>
>> On 07/04/2017 14:21, "Andy Seaborne" <an...@apache.org> wrote:
>>
>>
>>
>> On 07/04/17 11:26, Osma Suominen wrote:
>>> 05.04.2017, 20:32, Andy Seaborne kirjoitti:
>>>> If we have a 3.x.0/clocktick style, maybe we can better evolve more
>>>> easily - removing deprecations for example.
>>>
>>> What do you mean by clocktick style? Do you mean the .0/.1/.0/.1 style
>>> that has been followed recently (until 3.3.0 which will break the
>>> pattern) or the opposite where most/all releases are just 3.x.0?
>>>
>>>> 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 think there are two options:
>>>
>>> 1. Make an explicit strategy of alternating between .0 and .1 releases.
>>> Big changes can only go into .0 releases, while .1 releases are reserved
>>> for non-intrusive fixes.
>>>
>>> 2. Generally do only x.x.0 releases. However, if a "brown paper bag"
>>> issue comes up soon after a release, we could still do a .1 to fix just
>>> that specific issue.
>>>
>>> I like 2. more than 1. because it allows more freedom for subsystems to
>>> evolve on their own.
>>
>> +1 to (2)
>>
>> That is what I was getting at.
>>
>> This makes our work as decoupled/asynchronous as possible.
>>
>> This is not a big change. We have fallen into x.y.1 but I think because
>> that is what maven release plugin defaults to, no other reason.
>>
>> A (3) is two branches - dev and maintenance each with releases. Given
>> we are people-time-limited, I feel that's not viable.
>>
>>>
>>> -Osma
>>>
>>
>> Andy
>>
>>
>>
>>
>>
>
Re: Release 3.3.0?
Posted by "A. Soroka" <aj...@virginia.edu>.
I'm fine with trying for regular x.x.0 releases, but I would add two provisos:
1) We should have a calendar as well, particularly while we have a single codebase with two sync'd release products. In other words, we should do a release when either enough development has accumulated to justify a minor release or six months have passed. Otherwise we are waiting for arbitrary unscheduled work to complete to be able to release.
2) We need to develop some kind of strategy for maintaining a core and "exterior" modules. We've already begun those discussions and I don't think anyone is opposed to this. Having a large codebase completely locked together is not a good stance for flexibility or being able to do releases.
Lastly, if no one else (modulo Andy) is interested, and if Andy would rather not, I will do the 3.3.0 release. But having done the last one, let me encourage any committers who haven't released to think about doing it. It wasn't difficult and I got to learn a good bit about Apache release mechanics quickly.
---
A. Soroka
The University of Virginia Library
> On Apr 7, 2017, at 9:38 AM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>
> A big +1 to the proposed strategy
>
> Having more regular releases with whatever is ready is preferable to holding back work for the right release
>
> Rob
>
> On 07/04/2017 14:21, "Andy Seaborne" <an...@apache.org> wrote:
>
>
>
> On 07/04/17 11:26, Osma Suominen wrote:
>> 05.04.2017, 20:32, Andy Seaborne kirjoitti:
>>> If we have a 3.x.0/clocktick style, maybe we can better evolve more
>>> easily - removing deprecations for example.
>>
>> What do you mean by clocktick style? Do you mean the .0/.1/.0/.1 style
>> that has been followed recently (until 3.3.0 which will break the
>> pattern) or the opposite where most/all releases are just 3.x.0?
>>
>>> 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 think there are two options:
>>
>> 1. Make an explicit strategy of alternating between .0 and .1 releases.
>> Big changes can only go into .0 releases, while .1 releases are reserved
>> for non-intrusive fixes.
>>
>> 2. Generally do only x.x.0 releases. However, if a "brown paper bag"
>> issue comes up soon after a release, we could still do a .1 to fix just
>> that specific issue.
>>
>> I like 2. more than 1. because it allows more freedom for subsystems to
>> evolve on their own.
>
> +1 to (2)
>
> That is what I was getting at.
>
> This makes our work as decoupled/asynchronous as possible.
>
> This is not a big change. We have fallen into x.y.1 but I think because
> that is what maven release plugin defaults to, no other reason.
>
> A (3) is two branches - dev and maintenance each with releases. Given
> we are people-time-limited, I feel that's not viable.
>
>>
>> -Osma
>>
>
> Andy
>
>
>
>
>
Re: Release 3.3.0?
Posted by Rob Vesse <rv...@dotnetrdf.org>.
A big +1 to the proposed strategy
Having more regular releases with whatever is ready is preferable to holding back work for the right release
Rob
On 07/04/2017 14:21, "Andy Seaborne" <an...@apache.org> wrote:
On 07/04/17 11:26, Osma Suominen wrote:
> 05.04.2017, 20:32, Andy Seaborne kirjoitti:
>> If we have a 3.x.0/clocktick style, maybe we can better evolve more
>> easily - removing deprecations for example.
>
> What do you mean by clocktick style? Do you mean the .0/.1/.0/.1 style
> that has been followed recently (until 3.3.0 which will break the
> pattern) or the opposite where most/all releases are just 3.x.0?
>
>> 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 think there are two options:
>
> 1. Make an explicit strategy of alternating between .0 and .1 releases.
> Big changes can only go into .0 releases, while .1 releases are reserved
> for non-intrusive fixes.
>
> 2. Generally do only x.x.0 releases. However, if a "brown paper bag"
> issue comes up soon after a release, we could still do a .1 to fix just
> that specific issue.
>
> I like 2. more than 1. because it allows more freedom for subsystems to
> evolve on their own.
+1 to (2)
That is what I was getting at.
This makes our work as decoupled/asynchronous as possible.
This is not a big change. We have fallen into x.y.1 but I think because
that is what maven release plugin defaults to, no other reason.
A (3) is two branches - dev and maintenance each with releases. Given
we are people-time-limited, I feel that's not viable.
>
> -Osma
>
Andy
Re: Release 3.3.0?
Posted by Andy Seaborne <an...@apache.org>.
On 07/04/17 11:26, Osma Suominen wrote:
> 05.04.2017, 20:32, Andy Seaborne kirjoitti:
>> If we have a 3.x.0/clocktick style, maybe we can better evolve more
>> easily - removing deprecations for example.
>
> What do you mean by clocktick style? Do you mean the .0/.1/.0/.1 style
> that has been followed recently (until 3.3.0 which will break the
> pattern) or the opposite where most/all releases are just 3.x.0?
>
>> 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 think there are two options:
>
> 1. Make an explicit strategy of alternating between .0 and .1 releases.
> Big changes can only go into .0 releases, while .1 releases are reserved
> for non-intrusive fixes.
>
> 2. Generally do only x.x.0 releases. However, if a "brown paper bag"
> issue comes up soon after a release, we could still do a .1 to fix just
> that specific issue.
>
> I like 2. more than 1. because it allows more freedom for subsystems to
> evolve on their own.
+1 to (2)
That is what I was getting at.
This makes our work as decoupled/asynchronous as possible.
This is not a big change. We have fallen into x.y.1 but I think because
that is what maven release plugin defaults to, no other reason.
A (3) is two branches - dev and maintenance each with releases. Given
we are people-time-limited, I feel that's not viable.
>
> -Osma
>
Andy
Re: Release 3.3.0?
Posted by Osma Suominen <os...@helsinki.fi>.
05.04.2017, 20:32, Andy Seaborne kirjoitti:
> If we have a 3.x.0/clocktick style, maybe we can better evolve more
> easily - removing deprecations for example.
What do you mean by clocktick style? Do you mean the .0/.1/.0/.1 style
that has been followed recently (until 3.3.0 which will break the
pattern) or the opposite where most/all releases are just 3.x.0?
> 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 think there are two options:
1. Make an explicit strategy of alternating between .0 and .1 releases.
Big changes can only go into .0 releases, while .1 releases are reserved
for non-intrusive fixes.
2. Generally do only x.x.0 releases. However, if a "brown paper bag"
issue comes up soon after a release, we could still do a .1 to fix just
that specific issue.
I like 2. more than 1. because it allows more freedom for subsystems to
evolve on their own.
-Osma
--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: Release 3.3.0?
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org> 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 <an...@apache.org> 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.
>>>
>
Re: Release 3.3.0?
Posted by "A. Soroka" <aj...@virginia.edu>.
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 <an...@apache.org> 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 <an...@apache.org> 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.
>>
Re: Release 3.3.0?
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org> 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.
>
Re: Release 3.3.0?
Posted by "A. Soroka" <aj...@virginia.edu>.
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?
---
A. Soroka
The University of Virginia Library
> On Apr 5, 2017, at 10:25 AM, Andy Seaborne <an...@apache.org> 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.