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 <[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.
