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
