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