Took the liberty to update the confluence wiki to reflect the "create branch
off last released tag with only delta required" for hotfixes.
https://cwiki.apache.org/confluence/display/CASSANDRA/Patching%2C+versioning%2C+and+LTS+releases
If anyone disagrees please let me know.
On Tue, Feb 15,
Any committer can submit a devbranch build...
Kind Regards,
Brandon
On Tue, Feb 15, 2022 at 1:58 PM Mick Semb Wever wrote:
>
>
>
>> We've done concurrent releases without security before, and you follow much
>> closer than others. I feel most people, if they saw all of the changes
>> reverted
We've done concurrent releases without security before, and you follow much
> closer than others. I feel most people, if they saw all of the
> changes reverted and a release of a single fix, would either instantly know
> it's security (high confidence pointer to exactly which patch) OR assume
>
Correct. No need to revert anything or keep extra branches around. You just
checkout the tag and then make a branch with the single fix on it.
> On Feb 15, 2022, at 10:08 AM, Josh McKenzie wrote:
>
>
> Was thinking that too after I wrote this. Means we'd only need to change our
> process
Was thinking that too after I wrote this. Means we'd only need to change our
process for future hotfixes and keep everything else as-is.
On Tue, Feb 15, 2022, at 10:55 AM, Brandon Williams wrote:
> On Tue, Feb 15, 2022 at 9:53 AM Josh McKenzie wrote:
> >
> > The only way I'd be in favor of a
On Tue, Feb 15, 2022 at 9:53 AM Josh McKenzie wrote:
>
> The only way I'd be in favor of a release that removes all other committed
> patches
>
> Couldn't we just have a snapshot branch for each supported major/minor
> release branch that we patch for hotfixes and we bump up whenever we have a
te.
>
> I wonder if we need to find a way to produce binaries without leaving an
> obvious public mark (i.e. private CI, private branch)
>
>
> From: Josh McKenzie
> Date: Tuesday, 15 February 2022 at 14:09
> To: dev@cassandra.apache.org
> Subject: [DISCUSS] Hotfix rele
> The only way I'd be in favor of a release that removes all other committed
> patches
Couldn't we just have a snapshot branch for each supported major/minor release
branch that we patch for hotfixes and we bump up whenever we have a GA on a
parent branch?
Shouldn't be any extra burden other
to find a way to produce binaries without leaving an
> obvious public mark (i.e. private CI, private branch)
>
>
>
>
>
> *From: *Josh McKenzie
> *Date: *Tuesday, 15 February 2022 at 14:09
> *To: *dev@cassandra.apache.org
> *Subject: *[DISCUSS] Hotfix release proce
> obvious public mark (i.e. private CI, private branch)
>
>
> From: Josh McKenzie
> Date: Tuesday, 15 February 2022 at 14:09
> To: dev@cassandra.apache.org
> Subject: [DISCUSS] Hotfix release procedure
>
> On the release thread for 4.0.2 Jeremiah brought up a
: Tuesday, 15 February 2022 at 14:09
To: dev@cassandra.apache.org
Subject: [DISCUSS] Hotfix release procedure
On the release thread for 4.0.2 Jeremiah brought up a point about hotfix
releases and CI:
https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
If we are making this release
+1
On Tue, Feb 15, 2022 at 8:09 AM Josh McKenzie wrote:
>
> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix
> releases and CI:
> https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
>
> If we are making this release for a security incident/data loss/hot fix
+1. If we want to take our release quality seriously then I think this would be
a great policy to have.
> On Feb 15, 2022, at 8:09 AM, Josh McKenzie wrote:
>
>
> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix
> releases and CI:
>
On the release thread for 4.0.2 Jeremiah brought up a point about hotfix
releases and CI:
https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
> If we are making this release for a security incident/data loss/hot fix
> reason, then I would expect to see the related change set only
14 matches
Mail list logo
