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 <[email protected]> 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 <[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. >>>>>> >>>> >>
