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.
