You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Matt Doran <ma...@papercut.com> on 2009/11/26 06:14:40 UTC
Plans for a 10.5.3.1?
Hi guys,
It's 3 months since 10.5.3.0 and there appears to be a few nice fixes
lined up for a 10.5.3.1 (see link below). Are there any plans for
rolling this release?
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10594&fixfor=12314182
<https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10594&fixfor=12314182>
Thanks,
--
Matt Doran
PaperCut Software
http://www.papercut.com/
Re: Use of Jira "Fix In"
Posted by Myrna van Lunteren <m....@gmail.com>.
On Fri, Nov 27, 2009 at 12:55 AM, Knut Anders Hatlen
<Kn...@sun.com> wrote:
> Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:
>
>> Kristian Waagan <Kr...@Sun.COM> writes:
>>
>>> I believe we are supposed to set the fix version to the version shown
>>> by sysinfo. On the 10.5 branch it currently shows 10.5.3.1.
>>> Further I thought that when / if we decide to produce a 10.5.4.X, Jira
>>> is used to bulk update all issues with fix version set to 10.5.3.1
>>> such that they will have 10.5.4.0 set instead. Finally, wouldn't we
>>> remove 10.5.3.1 from the list of versions in Jira, by merging it with
>>> 10.5.4.0?
>
> I think the above is actually a single step: Merge 10.5.3.1 into
> 10.5.4.0. This will make all the issues marked as fixed in 10.5.3.1 show
> up as fixed in 10.5.4.0, and no bulk update is needed up front.
>
>> This makes sense, really. But then, why have we added 10.5.4.0 to JIRA
>> already?
>
> To have the possibility to flag that an issue is intended to be fixed in
> the next update release. But since the current policy is to set the
> fixed-in only after the issue has actually been fixed, I don't think
> having that version tag available adds much value, and I'm +1 to
> removing it in order to keep the list of version tags shorter and less
> confusing.
>
>> Several of us have marked issue for fix in 10.5.4.0 already; should we
>> go over those and clear that field, do you think? (as well as making
>> sure 10.5.3.1 is set - and similarly for older branches..)
>
> It would make the bug database more consistent, so feel free... :)
>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=12314154&sorter/field=issuekey&sorter/order=DESC
>
> In this list, at least three issues (DERBY-4081, DERBY-4092, DERBY-4213)
> were originally marked as fixed in 10.5.3.1 (this can be seen by picking
> the "All" tab). For some reason, the fix version says 10.5.4.0. All of
> these issues were fixed after the 10.5.3.0 release was produced and
> before it was actually released, so I'd guess something went wrong in
> the process of merging version tags into 10.5.3.0.
>
> --
> Knut Anders
>
So...we mark things 10.5.3.1, and if/when a next version is released,
it'll get merged into 10.5.4.0 (or 10.5.4.1, or whatever) in jira.
If we agree to mark things fixed in 10.5.3.1, it doesn't matter
whether we remove 10.5.4.0 or leave it in - except for the confusion
it causes...
I guess we should mark the 10.5.4.0 fixed issues as 10.5.3.1, then...
Myrna
Re: Use of Jira "Fix In"
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Rick Hillegas <Ri...@Sun.COM> writes:
> Branch LastOfficialRelease VersionOnBranch HighestJiraVersion
>
> 10.1 10.1.3.1 10.1.3.3 10.1.4.0
>
> 10.2 10.2.2.0 10.2.2.1 10.2.3.0
>
> 10.3 10.3.3.0 10.3.3.1 10.3.4.0
>
> 10.4 10.4.2.0 10.4.2.1 10.4.3.0
>
> 10.5 10.5.3.0 10.5.3.1 10.5.4.0
I have merged:
10.5.4.0 into 10.5.3.1 and labeled it head of 10.5 branch
10.4.3.0 into 10.4.2.1 and labeled it head of 10.4 branch
10.3.4.0 into 10.3.3.1 and labeled it head of 10.3 branch
10.2.3.0 into 10.2.2.1 and labeled it head of 10.2 branch
10.1.4.0 into 10.1.3.3 and labeled it head of 10.1 branch
(10.1.3.3 is also labeled "Maintenance version bump for sps update".
22/Oct/08.)
10.7.0.0 is labeled head of trunk.
10.6.1.1 is labeled head of 10.6 branch.
Dag
Re: Use of Jira "Fix In"
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:
> Knut Anders Hatlen <Kn...@Sun.COM> writes:
>
>> Rick Hillegas <Ri...@Sun.COM> writes:
>>
>>> I would support eliminating all of the HighestJiraVersion tags and
>>> merging those issues down to the corresponding VersionOnBranch.
>>
>> +1
>
> Seems we have agreement on this, then. If nobody objects, I volunteer
> to do it in a few days.
I had forgotten about this, I will do the merge now, so heads-up!
Dag
Re: Use of Jira "Fix In"
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Knut Anders Hatlen <Kn...@Sun.COM> writes:
> Rick Hillegas <Ri...@Sun.COM> writes:
>
>> I would support eliminating all of the HighestJiraVersion tags and
>> merging those issues down to the corresponding VersionOnBranch.
>
> +1
Seems we have agreement on this, then. If nobody objects, I volunteer
to do it in a few days.
Dag
Re: Use of Jira "Fix In"
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Rick Hillegas <Ri...@Sun.COM> writes:
> I would support eliminating all of the HighestJiraVersion tags and
> merging those issues down to the corresponding VersionOnBranch.
+1
--
Knut Anders
Re: Use of Jira "Fix In"
Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks for raising this topic, Dag. I don't think we have a clear
policy, as evidenced by the fact that we re-open some version of this
conversation every couple months. Here's what we've got for our branches
today:
Branch LastOfficialRelease VersionOnBranch HighestJiraVersion
10.1 10.1.3.1 10.1.3.3 10.1.4.0
10.2 10.2.2.0 10.2.2.1 10.2.3.0
10.3 10.3.3.0 10.3.3.1 10.3.4.0
10.4 10.4.2.0 10.4.2.1 10.4.3.0
10.5 10.5.3.0 10.5.3.1 10.5.4.0
trunk n/a 10.6.0.0 10.6.0.0
For all of the branches, we have a JIRA id for LastOfficialRelease,
VersionOnBranch, and HighestJiraVersion. Given the community's current
processes, I don't see a reason for JIRA to maintain both
VersionOnBranch and HighestJiraVersion. What we do now is record the
fact that a bug has been fixed at the head of the branch
(VersionOnBranch). The release manager bulk-updates the fixed-in-version
when producing a real release candidate.
I would support eliminating all of the HighestJiraVersion tags and
merging those issues down to the corresponding VersionOnBranch.
My $0.02,
-Rick
Knut Anders Hatlen wrote:
> Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:
>
>
>> Kristian Waagan <Kr...@Sun.COM> writes:
>>
>>
>>> I believe we are supposed to set the fix version to the version shown
>>> by sysinfo. On the 10.5 branch it currently shows 10.5.3.1.
>>> Further I thought that when / if we decide to produce a 10.5.4.X, Jira
>>> is used to bulk update all issues with fix version set to 10.5.3.1
>>> such that they will have 10.5.4.0 set instead. Finally, wouldn't we
>>> remove 10.5.3.1 from the list of versions in Jira, by merging it with
>>> 10.5.4.0?
>>>
>
> I think the above is actually a single step: Merge 10.5.3.1 into
> 10.5.4.0. This will make all the issues marked as fixed in 10.5.3.1 show
> up as fixed in 10.5.4.0, and no bulk update is needed up front.
>
>
>> This makes sense, really. But then, why have we added 10.5.4.0 to JIRA
>> already?
>>
>
> To have the possibility to flag that an issue is intended to be fixed in
> the next update release. But since the current policy is to set the
> fixed-in only after the issue has actually been fixed, I don't think
> having that version tag available adds much value, and I'm +1 to
> removing it in order to keep the list of version tags shorter and less
> confusing.
>
>
>> Several of us have marked issue for fix in 10.5.4.0 already; should we
>> go over those and clear that field, do you think? (as well as making
>> sure 10.5.3.1 is set - and similarly for older branches..)
>>
>
> It would make the bug database more consistent, so feel free... :)
>
>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=12314154&sorter/field=issuekey&sorter/order=DESC
>>
>
> In this list, at least three issues (DERBY-4081, DERBY-4092, DERBY-4213)
> were originally marked as fixed in 10.5.3.1 (this can be seen by picking
> the "All" tab). For some reason, the fix version says 10.5.4.0. All of
> these issues were fixed after the 10.5.3.0 release was produced and
> before it was actually released, so I'd guess something went wrong in
> the process of merging version tags into 10.5.3.0.
>
>
Re: Use of Jira "Fix In"
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:
> Kristian Waagan <Kr...@Sun.COM> writes:
>
>> I believe we are supposed to set the fix version to the version shown
>> by sysinfo. On the 10.5 branch it currently shows 10.5.3.1.
>> Further I thought that when / if we decide to produce a 10.5.4.X, Jira
>> is used to bulk update all issues with fix version set to 10.5.3.1
>> such that they will have 10.5.4.0 set instead. Finally, wouldn't we
>> remove 10.5.3.1 from the list of versions in Jira, by merging it with
>> 10.5.4.0?
I think the above is actually a single step: Merge 10.5.3.1 into
10.5.4.0. This will make all the issues marked as fixed in 10.5.3.1 show
up as fixed in 10.5.4.0, and no bulk update is needed up front.
> This makes sense, really. But then, why have we added 10.5.4.0 to JIRA
> already?
To have the possibility to flag that an issue is intended to be fixed in
the next update release. But since the current policy is to set the
fixed-in only after the issue has actually been fixed, I don't think
having that version tag available adds much value, and I'm +1 to
removing it in order to keep the list of version tags shorter and less
confusing.
> Several of us have marked issue for fix in 10.5.4.0 already; should we
> go over those and clear that field, do you think? (as well as making
> sure 10.5.3.1 is set - and similarly for older branches..)
It would make the bug database more consistent, so feel free... :)
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=12314154&sorter/field=issuekey&sorter/order=DESC
In this list, at least three issues (DERBY-4081, DERBY-4092, DERBY-4213)
were originally marked as fixed in 10.5.3.1 (this can be seen by picking
the "All" tab). For some reason, the fix version says 10.5.4.0. All of
these issues were fixed after the 10.5.3.0 release was produced and
before it was actually released, so I'd guess something went wrong in
the process of merging version tags into 10.5.3.0.
--
Knut Anders
Use of Jira "Fix In" [was: Re: Plans for a 10.5.3.1?]
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Kristian Waagan <Kr...@Sun.COM> writes:
> I believe we are supposed to set the fix version to the version shown
> by sysinfo. On the 10.5 branch it currently shows 10.5.3.1.
> Further I thought that when / if we decide to produce a 10.5.4.X, Jira
> is used to bulk update all issues with fix version set to 10.5.3.1
> such that they will have 10.5.4.0 set instead. Finally, wouldn't we
> remove 10.5.3.1 from the list of versions in Jira, by merging it with
> 10.5.4.0?
This makes sense, really. But then, why have we added 10.5.4.0 to JIRA
already?
Several of us have marked issue for fix in 10.5.4.0 already; should we
go over those and clear that field, do you think? (as well as making
sure 10.5.3.1 is set - and similarly for older branches..)
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=12314154&sorter/field=issuekey&sorter/order=DESC
>
> I may very well have gotten this wrong, please correct me if I'm mistaken!
> There are also some details missing regarding when a new version is
> added to Jira, and when the version is bumped on the branch. Any
> takers?
Yes, the write-up here:
http://wiki.apache.org/db-derby/DerbySnapshotOrRelease is a bit short
on detail on what happens on a branch after it's been cut the first
time..
Re: Plans for a 10.5.3.1?
Posted by Kristian Waagan <Kr...@Sun.COM>.
Dag H. Wanvik wrote:
> Kathey Marsden <km...@sbcglobal.net> writes:
>
>
>> Matt Doran wrote:
>>
>>> Hi guys,
>>>
>>> It's 3 months since 10.5.3.0 and there appears to be a few nice
>>> fixes lined up for a 10.5.3.1 (see link below). Are there any
>>> plans for rolling this release?
>>>
>
> Btw, it seems we have a somewhat inconsistent practice of marking
> backported fixes as fixed in "10.5.3.1" vs. "10.5.4.0" or both (and
> similarly for older branches than 10.5). What is the correct practice
> here?
>
Hi Dag,
I believe we are supposed to set the fix version to the version shown by
sysinfo. On the 10.5 branch it currently shows 10.5.3.1.
Further I thought that when / if we decide to produce a 10.5.4.X, Jira
is used to bulk update all issues with fix version set to 10.5.3.1 such
that they will have 10.5.4.0 set instead. Finally, wouldn't we remove
10.5.3.1 from the list of versions in Jira, by merging it with 10.5.4.0?
I may very well have gotten this wrong, please correct me if I'm mistaken!
There are also some details missing regarding when a new version is
added to Jira, and when the version is bumped on the branch. Any takers?
Regards,
--
Kristian
> Dag
>
Re: Plans for a 10.5.3.1?
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Kathey Marsden <km...@sbcglobal.net> writes:
> Matt Doran wrote:
>> Hi guys,
>>
>> It's 3 months since 10.5.3.0 and there appears to be a few nice
>> fixes lined up for a 10.5.3.1 (see link below). Are there any
>> plans for rolling this release?
Btw, it seems we have a somewhat inconsistent practice of marking
backported fixes as fixed in "10.5.3.1" vs. "10.5.4.0" or both (and
similarly for older branches than 10.5). What is the correct practice
here?
Dag
Re: Plans for a 10.5.3.1?
Posted by Kathey Marsden <km...@sbcglobal.net>.
Matt Doran wrote:
> Hi guys,
>
> It's 3 months since 10.5.3.0 and there appears to be a few nice fixes
> lined up for a 10.5.3.1 (see link below). Are there any plans for
> rolling this release?
>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10594&fixfor=12314182
> <https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10594&fixfor=12314182>
>
I have not heard of any plans for an immediate release, but if you want
to build it yourself to take advantage of the fixes, there should be no
upgrade issues associated with using it or upgrading to the next release
and we would appreciate the early feedback.
Thanks
Kathey