Re: CEP-15 Update

Congrats all! My previous reservations (that have been addressed) aside, this is an amazing milestone. Awesome, awesome work! Jordan On Thu, Apr 17, 2025 at 15:07 David Capwell wrote: > I have merged cep-15-accord into trunk. If you experience any issues > please reach out to me > > > On Apr 1

Re: CEP-15 Update

I have merged cep-15-accord into trunk. If you experience any issues please reach out to me > On Apr 17, 2025, at 12:55 AM, Benedict Elliott Smith > wrote: > > Final update: David has completed a second rebase after we reached parity > with trunk on our CI, and has confirmed tests remain sta

Re: [VOTE] Simplifying our release versioning process

+1 On Fri, 18 Apr 2025 at 3:59 AM, Josh McKenzie wrote: > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > >1. We no longer use semver .MINOR >2. Online upgrades are supported for all GA supported releases a

Re: [VOTE] Simplifying our release versioning process

+1 To the point on breaking changes and deprecations, I'd like to maintain a *very* high bar for user API-breaking changes – much higher than "our rules allow us to". Any time we break users, the project loses release uptake and creates friction for the community. – Scott On Apr 17, 2025, at 2:

Re: [VOTE] Simplifying our release versioning process

+1 On Thu, Apr 17, 2025 at 12:14 Jeremiah Jordan wrote: > +1 > > On Apr 17, 2025 at 10:58:24 AM, Josh McKenzie > wrote: > >> [DISCUSS] thread: >> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq >> >> The proposed new versioning mechanism: >> >>1. We no longer use semver .MI

Re: [VOTE] Simplifying our release versioning process

+1 On Apr 17, 2025 at 10:58:24 AM, Josh McKenzie wrote: > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > >1. We no longer use semver .MINOR >2. Online upgrades are supported for all GA supported releases

Re: [DISCUSS] How we version our releases

> Does it mean that one has to flag a feature as deprecated in the unreleased > version N, wait until when N is released (deprecating for one major cycle), > and then finally make the breaking change in N + 1? My understanding is things are not different than before, we just don’t do minors; wh

Re: [DISCUSS] How we version our releases

Just realized that the other thread is for [vote]. Posting my question here instead... I would like to get a better understanding of "but only for features that have already been deprecated for one major release cycle." Does it mean that one has to flag a feature as deprecated in the unreleased v

Re: [VOTE] Simplifying our release versioning process

I would like to get a better understanding of "but only for features that have already been deprecated for one major release cycle." Does it mean that one has to flag a feature as deprecated in the unreleased version N, wait until when N is released (deprecating for one major cycle), and then fina

Re: [VOTE] Simplifying our release versioning process

+1 Kind Regards, Brandon On Thu, Apr 17, 2025 at 10:59 AM Josh McKenzie wrote: > > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > > We no longer use semver .MINOR > Online upgrades are supported for all GA suppor

Re: [VOTE] Simplifying our release versioning process

+1 > On Apr 17, 2025, at 9:22 AM, Jon Haddad wrote: > > +1 > > On Thu, Apr 17, 2025 at 9:15 AM Josh McKenzie > wrote: >> +1 >> >> On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote: >>> [DISCUSS] thread: >>> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz

Re: [VOTE] Simplifying our release versioning process

+1 On Thu, Apr 17, 2025 at 9:15 AM Josh McKenzie wrote: > +1 > > On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote: > > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > >1. We no longer use semver .MINOR >

Re: Constraint's "not null" alignment with transactions and their simplification

Maybe I misremember the convo, but I thought both of these was possible: CREATE table test ( id int primary key val int check val > 0, val2 int ) INSERT INTO test (id) values (1); ## inserts with empty val UPDATE test set val2 = 1; ## inserts with empty val Are you saying supplying val is req

Re: [VOTE] Simplifying our release versioning process

+1 On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote: > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > 1. We no longer use semver .MINOR > 2. Online upgrades are supported for all GA supported releases at t

[VOTE] Simplifying our release versioning process

[DISCUSS] thread: https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq The proposed new versioning mechanism: 1. We no longer use semver .MINOR 2. Online upgrades are supported for all GA supported releases at time of new .MAJOR 3. T-1 releases are guaranteed API compatible for no

Re: CEP-15 Update

Final update: David has completed a second rebase after we reached parity with trunk on our CI, and has confirmed tests remain stable. So I expect CEP-15 to merge to trunk sometime today. No doubt there will be some unexpected disruption to others after a patch like this lands. Reach out via sl