I understood us to have agreed to drop semver, because our major/minor history
has been a meaningless distinction, and instead to go major/patch (or
major/minor - with minor for patches), depending how you want to slice it.
But there have been a lot of discussions over the past year or so, so I may be
misremembering.
On 27/01/2021, 13:25, "Benjamin Lerer" <benjamin.le...@datastax.com> wrote:
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
