For a minor/major? I can imagine doing this for a patch version, but this is of
much less importance to downstream users.
Do you have any examples of projects that do this for major/minor development
branches, as you propose?
I'm just a bit confused about the proposition to decouple from releas
> > Vendors are also free to support and provide hot-fixes and back ports on
> > these unreleased versions, outside of the community's efforts or concerns
>
> This seems to me like we're endorsing the release of these versions by
> downstream maintainers? Even if we decide to modify this proposal
> Vendors are also free to support and provide hot-fixes and back ports on
> these unreleased versions, outside of the community's efforts or concerns
This seems to me like we're endorsing the release of these versions by
downstream maintainers? Even if we decide to modify this proposal and say
> Well the other problem I see is that this could create a lot of confusion for
> our users, if more versions start popping up (and/or versions are skipped).
> It's hard to row back from unwanted versions in the wild, and we may end up
> having to either support them or disappoint our users.
T
Well the other problem I see is that this could create a lot of confusion for
our users, if more versions start popping up (and/or versions are skipped).
It's hard to row back from unwanted versions in the wild, and we may end up
having to either support them or disappoint our users.
Do we have
> Hmm, ok. I see some possible issues with this. You mention one possibility,
> i.e. that downstream may end up releasing these versions for us? Which
> potentially complicates our lives, whether we want it or not.
>
> Would this apply to only trunk, or to all existing major/minor releases?
Onl
Hmm, ok. I see some possible issues with this. You mention one possibility,
i.e. that downstream may end up releasing these versions for us? Which
potentially complicates our lives, whether we want it or not.
Would this apply to only trunk, or to all existing major/minor releases?
I wonder if
> Sorry, I may be being dense, but it's not that I didn't parse your
> justification for it, but that I literally don't understand what the proposal
> is.
Ah, nothing more than every quarter we bump the minor version in build.xml
(the frequency is up for discussion)
---
Sorry, I may be being dense, but it's not that I didn't parse your
justification for it, but that I literally don't understand what the proposal
is.
On 03/05/2021, 08:30, "Mick Semb Wever" wrote:
> I didn't really understand the unreleased versions proposal though.
Benedict, two bri
> I didn't really understand the unreleased versions proposal though.
Benedict, two brief example perspectives on it. This is all under the
"let's try, learn, evaluate" umbrella.
1)
Unreleased versions can give downstream more choices through the
annual development cycle than the binary choice o
Big +1
On 30/4/21 23:29, Benedict Elliott Smith wrote:
> +1 to semver, shippable trunk, feature flags, and better documentation about
> feature support and compatibility edges - we should have a single page with a
> table of version x feature, with a summary and links to detailed explanations
>
+1 to semver, shippable trunk, feature flags, and better documentation about
feature support and compatibility edges - we should have a single page with a
table of version x feature, with a summary and links to detailed explanations
of everything important a user should be aware of.
I didn't re
Success of this seems predicated on keeping trunk shippable, which means
getting Harry and things like adelphi into CI/CD sooner rather than later.
I've definitely come around to Ariel's thinking about the value of having
an *actually* shippable trunk + the value of feature flags for things. It's
+1 for doing this (or something similar). It will give more clarity to
downstream users about the compatibility of a given release.
-Jeremiah
> On Apr 30, 2021, at 12:45 PM, Mick Semb Wever wrote:
>
> *** Proposal ***
> Aligned to the agreed-upon annual cadence of supported releases, let's
>
*** Proposal ***
Aligned to the agreed-upon annual cadence of supported releases, let's
use semantic versioning for better ecosystem operatibility, and to
promote API awareness and compatibility support from documentation to
tests.
*** Background ***
The recent¹ dev ML thread 'Releases after 4.0'
15 matches
Mail list logo
