> > My preference is for a simple annual major release cadence, with minors as > necessary. >
I do not think that I fully understand your proposal. How do you define a major and a minor release? My understanding of a major release was a version that broke some of the compatibilities. By consequence, once a breaking change has been introduced it will not be possible to release a minor and we will have to wait for a major release. In a similar way if no breaking change has been introduced, does it make sense to release a major? On Wed, Jan 27, 2021 at 11:21 AM Benedict Elliott Smith <bened...@apache.org> wrote: > Perhaps we could also consider quarterly "develop" releases, so that we > have pressure to maintain a shippable trunk? This provides some opportunity > for more releases without incurring the project maintenance costs or user > coordination costs. Something like a feature-incomplete mid-cycle RC, that > a user wanting shiny features can grab, providing feedback throughout the > development cycle. > > On 26/01/2021, 14:11, "Benedict Elliott Smith" <bened...@apache.org> > wrote: > > My preference is for a simple annual major release cadence, with > minors as necessary. This is simple for the user community and developer > community: support = x versions = x years. > > I'd like to pair this with stricter merge criteria, so that we > maintain a ~shippable trunk, and we cut a release at ~the same time every > year, whatever features are merged. We might have to get happy with > reverting commits that break things. > > I think faster cadences impose too much burden on the developer > community for maintenance and the user community for both upgrades and > making sense of what's going on. I think slower cadences collapse, as the > release window begins to collect too many hopes and dreams. > > My hope is that we get to a point where snapshots of trunk are safe to > run, and that major contributors are ahead of the release window for > internal consumption, rather than behind - this might also alleviate > pressure for hitting release windows with features. > > > > > On 26/01/2021, 13:56, "Benjamin Lerer" <benjamin.le...@datastax.com> > wrote: > > Hi everybody > > It seems that there is a need to discuss how we will deal with > releases > after 4.0 > We are now relatively close from the 4.0 RC release so it make > sense to me > to start discussing that subject especially as it has some impact > on some > things like dropping support for python 2 > > The main questions are in my opinion: > 1) What release cadence do we want to use for major/minor versions? > 2) How do we plan to ensure the quality of the releases? > > It might make sense to try a release cadence and see how it works > out in > practice revisiting our decision if we feel the need for it. > > One important thing to discuss with the cadence is the amount of > time we > want to support the releases. 2.2 has been supported for more than > 5 years, > we might not be able to support releases for a similar time frame > if we > release a version every 6 months for example. > To be sure that we are all on the same page regarding what minor > and major > versions are and their naming: 4.1 would be a minor version > (improvements > and features that don't break compatibility) and 5.0 would be a > major > version (compatibility breakages) > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
