> Why do you need to change anything post release? The whole point is to set
> the version to the release the ticket blocks. So you don’t need to change
> anything.
>
There's always many issues left with the wrong fixVersion. And we
can't police that. So at some later point it needs to be "eas
Overloading fixVersion shouldn't be a problem. IIRC you can:
- bulk update
- Merge versions:
https://support.atlassian.com/jira-work-management/docs/view-and-manage-a-projects-versions/#Merge-versions
We just need the permissions for jira to allow us to do it.
Regards
On 10/5/22 3:02, Mick
+1nb
> On May 9, 2022, at 5:24 PM, Mick Semb Wever wrote:
>
>
>>
>> > The vote will be open for 72 hours (longer if needed). Everyone who
>> > has tested the build is invited to vote. Votes by PMC members are
>> > considered binding. A vote passes if there are at least three binding
>> > +1s
+1nb
> On May 5, 2022, at 9:49 AM, Brandon Williams wrote:
>
> +1
>
> Also passed dependency-check
>
> Kind Regards,
> Brandon
>
>> On Wed, May 4, 2022 at 9:33 AM Mick Semb Wever wrote:
>>
>> Proposing the test build of Cassandra 4.0.4 for release.
>>
>> sha1: d4dbc932bf415e0ca17c43289147
+1, with special attention to CASSANDRA-14752 - didn’t realize we hadn’t
released a build with a resolution for this yet.
> On May 9, 2022, at 5:23 PM, Mick Semb Wever wrote:
>
>
>>
>> > The vote will be open for 72 hours (longer if needed). Everyone who
>> > has tested the build is invited
Why do you need to change anything post release? The whole point is to set the
version to the release the ticket blocks. So you don’t need to change anything.
> On May 9, 2022, at 8:03 PM, Mick Semb Wever wrote:
>
> Jeremiah, around when was this? I can see that it makes sense (works in
> the
>
>
> Thus anything unresolved flagged 4.1-alpha would be a blocker for that,
> same for beta and rc. When the tickets are closed, we switch them to
> FixVersion 4.1; I don't see there being much value in knowing in the future
> if a ticket is fixed during the alpha, beta, or rc phases by using the
>
>
> > The vote will be open for 72 hours (longer if needed). Everyone who
> > has tested the build is invited to vote. Votes by PMC members are
> > considered binding. A vote passes if there are at least three binding
> > +1s and no -1's.
> >
>
+1
Checked
- signing correct
- checksums are corr
>
>
> > The vote will be open for 72 hours (longer if needed). Everyone who
> > has tested the build is invited to vote. Votes by PMC members are
> > considered binding. A vote passes if there are at least three binding
> > +1s and no -1's.
> >
>
+1
Checked
- signing correct
- checksums are corr
And back to the point - 4.1.0 which? Alpha, beta or rc? As we have that on
the table too.
On Mon, 9 May 2022 at 18:59, David Capwell wrote:
> I am in favor of option 1. If you are 4.1.0 and not resolved, then we
> either need to kick you out of the 4.1.0 release (as you are not a blocker)
> or
I am in favor of option 1. If you are 4.1.0 and not resolved, then we either
need to kick you out of the 4.1.0 release (as you are not a blocker) or you are
a blocker for that release and must be fixed in 4.1.0
> On May 9, 2022, at 2:49 PM, bened...@apache.org wrote:
>
> I think this is close
I think this is close to what we settled on last we hashed this out.
From: Josh McKenzie
Date: Monday, 9 May 2022 at 22:47
To: dev@cassandra.apache.org
Subject: Re: How we flag tickets as blockers during freeze
As you mentioned on slack, we can introduce FixVersions for the unreleased
interim v
As you mentioned on slack, we can introduce FixVersions for the unreleased
interim versions specified in the lifecycle wiki
(https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle), so
add the following specific *unresolved placeholder FixVersions*:
4.1-alpha
4.1-beta
4.1-rc
T
I would vote for option 1. We have done similar in the past and if something is
a blocker it means it will be in that version before it is released. So there
should not be any confusion of things getting bumped forward to another patch
number because they were not committed in time, which is whe
>
> Any other opinions or ideas out there? Would like to tidy our tickets up
> as build lead and scope out remaining work for 4.1.
>
My request is that we don't overload fixVersions. That is, a fixVersion is
either for resolved tickets, or a placeholder for unresolved, but never
both.
This makes
We've chatted a touch on slack about this but haven't gotten resolution.
How are we flagging tickets as being 4.1 blockers?
Option 1: FixVersion 4.1.0, unresolved
Cons: confusing overload of FixVersion and breaks our "fixversion only set
on close" paradigm
Option 2: FixVersion 4.1.x, unresol
+1
Kind Regards,
Brandon
On Sat, May 7, 2022 at 1:39 AM Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.0.4 for release.
> This is from the (take4) test artifact.
>
> sha1: 052125f2c6ed308f1473355dfe43470f0da44364
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a
+1
Kind Regards,
Brandon
On Sat, May 7, 2022 at 1:38 AM Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 3.11.13 for release.
>
> sha1: 836ab2802521a685efe84382cb48db56caf4478d
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.13-tentative
+1
Kind Regards,
Brandon
On Sat, May 7, 2022 at 1:38 AM Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 3.0.27 for release.
>
> sha1: 205366131484967a3a8a749f1d1d841c952127e8
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.27-tentative
>
+1
On Sat, 7 May 2022 at 08:39, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 3.11.13 for release.
>
> sha1: 836ab2802521a685efe84382cb48db56caf4478d
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.13-tentative
> Maven Artifacts:
> htt
20 matches
Mail list logo
