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, 202
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
> som
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 for
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 rel
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
+1 (hotfix with only security fix, private vote, private branch & private ci)
On Tue, Feb 15, 2022 at 02:18:42PM +, bened...@apache.org wrote:
> One issue with this approach is that we are advertising that we are preparing
> a security release by preparing such a release candidate.
>
> I won
> 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 th
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
someone bot
We already advertise that we are preparing a security release when ever we
release all of our patch versions at the same time. So I don’t think there is
an issue there.
I was not involved in any PMC discussions and had no knowledge of the CVE, but
when three branches got release votes at the sam
One issue with this approach is that we are advertising that we are preparing a
security release by preparing such a release candidate.
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: Tues
+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:
> https://lists.apache.org/thread/7zc
13 matches
Mail list logo
