meaning of the two unreleased 10.8.1 versions

[Rick Hillegas <ri...@oracle.com>]

In addition to the well-defined 10.8.1.2 release version, there are two 
unreleased 10.8.1 versions in JIRA now: 10.8.1.3 and 10.8.1.4. Are both 
of these versions necessary or can 10.8.1.3 be merged into 10.8.1.4?

Thanks,
-Rick

Re: meaning of the two unreleased 10.8.1 versions

[Rick Hillegas <ri...@oracle.com>]

Thanks for the quick responses, Knut and Mike. I have merged 10.8.1.3 
into 10.8.1.4.

Regards,
-Rick

On 6/14/11 2:58 PM, Mike Matrigali wrote:
> I believe after a discussion on the list it was agreed that any
> committer could "bump" the version number in the branch for their
> own reasons.  The expectation was that  the number of versions
> would be reasonable and we would revisit if it seemed it was being
> abused.
>
> So far I think the only bumps have been associated with bug fixes
> in the branch where the bump was necessary to force the soft upgrade
> mechanism to fix some problem in compiled saved plans.  Open source
> users of Derby are allowed to take and build the branch code and make
> their own releases.  In this case those users may have a version
> of 10.8.1.3 to report a bug against, though it would be more useful
> in almost all cases if the bug were reported against the most recent
> official release and only reported against 10.8.1.3 if a regression was
> introduced into the branch after the release.
>
> I think it less likely that
> users would need to report a bug fixed against 10.8.1.3.
>
> Knut Anders Hatlen wrote:
>> Rick Hillegas <ri...@oracle.com> writes:
>>
>>> In addition to the well-defined 10.8.1.2 release version, there are
>>> two unreleased 10.8.1 versions in JIRA now: 10.8.1.3 and 10.8.1.4. Are
>>> both of these versions necessary or can 10.8.1.3 be merged into
>>> 10.8.1.4?
>>
>> 10.8.1.3 was the version number given to the head of the branch after
>> 10.8.1.2 was produced. The version number was later bumped to 10.8.1.4
>> so that upgrade would work for those following the branch after
>> DERBY-3870. Fixes that go into the 10.8 branch now should have 10.8.1.4
>> as the fix version.
>>
>> It is probably OK to merge 10.8.1.3 into 10.8.1.4 to reduce the size of
>> the drop-down list. Previously, I think we've only merged versions when
>> we produced a new release, but I don't see much value in keeping
>> 10.8.1.3 as a distinct version in the bug tracker. It looks like we have
>> similar situations on 10.1, 10.5 and 10.6.
>>
>
>

Re: meaning of the two unreleased 10.8.1 versions

[Mike Matrigali <mi...@sbcglobal.net>]

I believe after a discussion on the list it was agreed that any
committer could "bump" the version number in the branch for their
own reasons.  The expectation was that  the number of versions
would be reasonable and we would revisit if it seemed it was being
abused.

So far I think the only bumps have been associated with bug fixes
in the branch where the bump was necessary to force the soft upgrade
mechanism to fix some problem in compiled saved plans.  Open source
users of Derby are allowed to take and build the branch code and make
their own releases.  In this case those users may have a version
of 10.8.1.3 to report a bug against, though it would be more useful
in almost all cases if the bug were reported against the most recent
official release and only reported against 10.8.1.3 if a regression was
introduced into the branch after the release.

I think it less likely that
users would need to report a bug fixed against 10.8.1.3.

Knut Anders Hatlen wrote:
> Rick Hillegas <ri...@oracle.com> writes:
> 
>> In addition to the well-defined 10.8.1.2 release version, there are
>> two unreleased 10.8.1 versions in JIRA now: 10.8.1.3 and 10.8.1.4. Are
>> both of these versions necessary or can 10.8.1.3 be merged into
>> 10.8.1.4?
> 
> 10.8.1.3 was the version number given to the head of the branch after
> 10.8.1.2 was produced. The version number was later bumped to 10.8.1.4
> so that upgrade would work for those following the branch after
> DERBY-3870. Fixes that go into the 10.8 branch now should have 10.8.1.4
> as the fix version.
> 
> It is probably OK to merge 10.8.1.3 into 10.8.1.4 to reduce the size of
> the drop-down list. Previously, I think we've only merged versions when
> we produced a new release, but I don't see much value in keeping
> 10.8.1.3 as a distinct version in the bug tracker. It looks like we have
> similar situations on 10.1, 10.5 and 10.6.
> 

Re: meaning of the two unreleased 10.8.1 versions

[Knut Anders Hatlen <kn...@oracle.com>]

Rick Hillegas <ri...@oracle.com> writes:

> In addition to the well-defined 10.8.1.2 release version, there are
> two unreleased 10.8.1 versions in JIRA now: 10.8.1.3 and 10.8.1.4. Are
> both of these versions necessary or can 10.8.1.3 be merged into
> 10.8.1.4?

10.8.1.3 was the version number given to the head of the branch after
10.8.1.2 was produced. The version number was later bumped to 10.8.1.4
so that upgrade would work for those following the branch after
DERBY-3870. Fixes that go into the 10.8 branch now should have 10.8.1.4
as the fix version.

It is probably OK to merge 10.8.1.3 into 10.8.1.4 to reduce the size of
the drop-down list. Previously, I think we've only merged versions when
we produced a new release, but I don't see much value in keeping
10.8.1.3 as a distinct version in the bug tracker. It looks like we have
similar situations on 10.1, 10.5 and 10.6.

-- 
Knut Anders