Perhaps on my third try... keep three branches total, including 3.11:
3.11, 4, next. Support for 3.11 begins ending after next+1, is what
I'm trying to convey.
On Fri, Feb 5, 2021 at 2:58 PM Brandon Williams wrote:
>
> Err, to be clear: keep 3.11 until we have 3 other branches.
>
> On Fri, Feb 5
Err, to be clear: keep 3.11 until we have 3 other branches.
On Fri, Feb 5, 2021 at 2:57 PM Brandon Williams wrote:
>
> I'm +1 on 3 branches, and thus ~3 years of support. So in the
> transition, would we aim to keep 3.11 until after 4.0 and a successor
> are released?
>
> On Fri, Feb 5, 2021 at
I'm +1 on 3 branches, and thus ~3 years of support. So in the
transition, would we aim to keep 3.11 until after 4.0 and a successor
are released?
On Fri, Feb 5, 2021 at 11:44 AM Benjamin Lerer
wrote:
>
> >
> > Are we also trying to reach a consensus here that a release branch should
> > be suppo
>
> Are we also trying to reach a consensus here that a release branch should
> be supported for ~3 years (i.e. that we are aiming to limit ourselves to 3
> release branches plus trunk)?
3 release branches make sense to me +1
On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever wrote:
>
> > I b
> I believe that there is an appetite for the bleeding edge snapshots where
> we do not guarantee stability and that the semver discussion is not
> finished yet but I would like us to let those discussions go for some
> follow up threads.
> My goal with this thread was to reach an agreement on a
+1 to both yearly release and periodic snapshots.
As far as timing goes, I would like to avoid picking a specific date
for release, and instead choose something like "the first Wednesday of
May" or something.
On Fri, Feb 5, 2021 at 10:20 AM Sam Tunnicliffe wrote:
>
> +1 to both the yearly cadenc
+1 to both the yearly cadence and the periodic publishing of bleeding edge
snapshots.
> On 5 Feb 2021, at 16:14, Benedict Elliott Smith wrote:
>
> +1
>
> +1 also to mixing this with an experiment on regular "releasable" (without
> API stability) snapshots from trunk.
>
> On 05/02/2021, 16:0
+1
+1 also to mixing this with an experiment on regular "releasable" (without API
stability) snapshots from trunk.
On 05/02/2021, 16:07, "Joshua McKenzie" wrote:
+1 from me on the yearly cadence fwiw. The space this project is in (infra
software) is directly at odds for many users' pr
+1 from me on the yearly cadence fwiw. The space this project is in (infra
software) is directly at odds for many users' preferred release cadence
(preferably never or bugfix only for existing / stable projects) compared
to how fast the NoSQL / database ecosystem is evolving; once a year seems
to s
Thanks for your responses.
I had some offline discussions with different persons to gather more
feedback on the current discussion.
The people I talked to appeared to be in favor of one supported release
every year as Benedict initially suggested.
The advantages mentioned were:
* it is long enough
10 matches
Mail list logo
