You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Davide Giannella <da...@apache.org> on 2015/12/07 14:55:44 UTC
fixVersions in jira
Hello team,
would it be a problem for anyone if we start a new process of not
setting a fixVersion like 1.3.12 but setting such specific version only
when we actually fix or are (almost) sure to be able to fix the issue
before the release?
This is to ease the release process by having not to update every time a
bunch of issues for fixVersion.
The process I'm proposing is:
- fixVersion = 1.4
- fix it
- fixVersion = 1.3.x
If no objections, can you please take care of your own issues by
removing 1.3.13 and leaving 1.4?
By having 1.4 will have it showing up in the Oak board anyhow.
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=20
Cheers
Davide
Re: fixVersions in jira
Posted by Michael Dürig <md...@apache.org>.
+1. That's how I've been handling the issues assigned to me for a while
now.
Michael
On 7.12.15 2:55 , Davide Giannella wrote:
> Hello team,
>
> would it be a problem for anyone if we start a new process of not
> setting a fixVersion like 1.3.12 but setting such specific version only
> when we actually fix or are (almost) sure to be able to fix the issue
> before the release?
>
> This is to ease the release process by having not to update every time a
> bunch of issues for fixVersion.
>
> The process I'm proposing is:
>
> - fixVersion = 1.4
> - fix it
> - fixVersion = 1.3.x
>
> If no objections, can you please take care of your own issues by
> removing 1.3.13 and leaving 1.4?
>
> By having 1.4 will have it showing up in the Oak board anyhow.
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=20
>
> Cheers
> Davide
>
Re: fixVersions in jira
Posted by Julian Reschke <ju...@gmx.de>.
On 2015-12-09 10:33, Davide Giannella wrote:
> On 08/12/2015 16:06, Julian Reschke wrote:
>>
>> So what's the correct JIRA state for something that has been fixed in
>> 1.3.x, which is intended to be backported to 1.2, but hasn't been
>> backported yet? Can I still set that to "resolved"?
>
> If the backport is part of the issue no you can't. If the backport is
> difficult you can always mark the issue itself as resolved for 1.3 and
> open a separate ticket for the backporting.
>
> Davide
Well, that would essentially triple the number of tickets for me, and
will make it much harder later on to find what fix went where and when...
Best regards, Julian
Re: fixVersions in jira
Posted by Davide Giannella <da...@apache.org>.
On 08/12/2015 16:06, Julian Reschke wrote:
>
> So what's the correct JIRA state for something that has been fixed in
> 1.3.x, which is intended to be backported to 1.2, but hasn't been
> backported yet? Can I still set that to "resolved"?
If the backport is part of the issue no you can't. If the backport is
difficult you can always mark the issue itself as resolved for 1.3 and
open a separate ticket for the backporting.
Davide
Re: fixVersions in jira
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Tue, Dec 8, 2015 at 9:36 PM, Julian Reschke <ju...@gmx.de> wrote:
> So what's the correct JIRA state for something that has been fixed in 1.3.x,
> which is intended to be backported to 1.2, but hasn't been backported yet?
> Can I still set that to "resolved"?
So far the practice some of us follow is to add label
candidate_oak_1_0 or candidate_oak_1_2. See [1] for some earlier
discussion around this
Chetan Mehrotra
[1] http://markmail.org/thread/7sbse6lpgxaqgplv
Re: fixVersions in jira
Posted by Julian Reschke <ju...@gmx.de>.
On 2015-12-08 16:50, Davide Giannella wrote:
> On 08/12/2015 09:13, Julian Sedding wrote:
>> +1 - Setting the next release as fixVersion for blockers makes sense.
+1
> This is VERY important. As main release manager this is the only way I
> have to understand if a release should be blocked waiting on something
> or not. Normally is not an issue for the unstable cuts but it is when
> dealing with patch releases (stables. Not as in horses ;)).
>
> I will proceed de-scheduling all 1.3.x that are not resolved and set 1.4
> if missing.
So what's the correct JIRA state for something that has been fixed in
1.3.x, which is intended to be backported to 1.2, but hasn't been
backported yet? Can I still set that to "resolved"?
Best regards, Julian
Re: fixVersions in jira
Posted by Davide Giannella <da...@apache.org>.
On 08/12/2015 09:13, Julian Sedding wrote:
> +1 - Setting the next release as fixVersion for blockers makes sense.
This is VERY important. As main release manager this is the only way I
have to understand if a release should be blocked waiting on something
or not. Normally is not an issue for the unstable cuts but it is when
dealing with patch releases (stables. Not as in horses ;)).
I will proceed de-scheduling all 1.3.x that are not resolved and set 1.4
if missing.
Davide
Re: fixVersions in jira
Posted by Julian Sedding <js...@gmail.com>.
+1 - Setting the next release as fixVersion for blockers makes sense.
For all other issues setting the fixVersion once it is fixed seems
more sensible.
Regards
Julian
On Tue, Dec 8, 2015 at 8:27 AM, Marcel Reutegger <mr...@adobe.com> wrote:
> On 07/12/15 14:55, "Davide Giannella" wrote:
>>The process I'm proposing is:
>>
>>- fixVersion = 1.4
>>- fix it
>>- fixVersion = 1.3.x
>
> +1
>
> Regards
> Marcel
>
Re: fixVersions in jira
Posted by Marcel Reutegger <mr...@adobe.com>.
On 07/12/15 14:55, "Davide Giannella" wrote:
>The process I'm proposing is:
>
>- fixVersion = 1.4
>- fix it
>- fixVersion = 1.3.x
+1
Regards
Marcel
Re: fixVersions in jira
Posted by Vikas Saurabh <vi...@gmail.com>.
+1 to the idea. Additionally, we can probably setup a query to find issues
marked resolved in 1.4 while releasing and set fixForVersion according to
release being prepared.
-Vikas
(sent from mobile)
On 07-Dec-2015 7:25 pm, "Davide Giannella" <da...@apache.org> wrote:
> Hello team,
>
> would it be a problem for anyone if we start a new process of not
> setting a fixVersion like 1.3.12 but setting such specific version only
> when we actually fix or are (almost) sure to be able to fix the issue
> before the release?
>
> This is to ease the release process by having not to update every time a
> bunch of issues for fixVersion.
>
> The process I'm proposing is:
>
> - fixVersion = 1.4
> - fix it
> - fixVersion = 1.3.x
>
> If no objections, can you please take care of your own issues by
> removing 1.3.13 and leaving 1.4?
>
> By having 1.4 will have it showing up in the Oak board anyhow.
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=20
>
> Cheers
> Davide
>