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