The main topic seems to be that we need a way to identify the issues
that we want to solve for a stable release of oak-segment-tar. In a
quick offline conversation with Michael, we came up with the following
ideas - to be discussed - to track issues.
1. If an issue is not essential for the stable release of
oak-segment-tar, leave the fix version empty.
2. If an issue is essential for the stable release of oak-segment-tar,
set the fix version to one of the upcoming releases.
3. When a release is performed, if there are unresolved issues for
that release, move those issues to the next release.
Points 2 and 3 guarantee that the issues that we consider important
have visibility on the mailing list. If an issue is unresolved and is
postponed to the next release it will appear on the mailing list.
Point 1 guarantees that this will not happen for unimportant or
unplanned issues, reducing the noise considerably. This approach also
avoids the creation of Jira versions that have no meaning from a
semantic versioning point of view.
Looking forward to your opinions about this.
2016-07-29 15:21 GMT+02:00 Francesco Mari <mari.france...@gmail.com>:
> The question to answer now is what will happen if we release the 1.0.0
> version and we end up having 1.1.13 in Oak 1.6.
>
>
> On Jul 29, 2016 12:16 PM, "Michael Dürig" <mdue...@apache.org> wrote:
>>
>>
>> Hi,
>>
>> I went for adding a "Segment Tar 1.0.0" version. So far this is a place
>> holder for all we want to have released at the same time we release Oak 1.6.
>> That is, it is the "recommended version" to use along with Oak 1.6.
>>
>> Michael
>>
>>
>> On 29.7.16 10:57 , Davide Giannella wrote:
>>>
>>> On 27/07/2016 16:57, Michael Dürig wrote:
>>>>
>>>>
>>>> In a quick chat with Francesco we came up with a couple of ways of
>>>> achieving this. I.e. we want to have a mechanism to differentiate in
>>>> Jira between issues in oak-segment-tar that we want to have fixed once
>>>> Oak 1.6. is out and those that can be deferred:
>>>>
>>>> 1) Use fix version 1.6. This is confusing as 1.6 has no relation to
>>>> oak-segment-tar whatsoever and we risk messing up the release notes
>>>> for Oak 1.6
>>>>
>>>> 2) Introduce a fake version in Jira ("Oak Segment For Oak 1.6"). This
>>>> is a misuse of the version field probably leading to confusion later on.
>>>>
>>>> 3) Use a label. Might work but then labels are soooo overloaded and
>>>> weak. Also it is difficult to spot and align them in a table in Jira.
>>>>
>>>> 4) Resolve as later. But later is usually never...
>>>>
>>>> 5) Use the assignee field: unassigned issues are tackled post Oak 1.6
>>>> all others are planed to be tackled until Oak 1.6.
>>>>
>>>> My preference would be 5).
>>>
>>>
>>> Well the fixVersion field can have multiple values. So I would say that
>>> for segment we have 2 or 3 targets for solving issues.
>>>
>>> 1) stuff that needs to be solved before oak 1.6
>>> 2) stuff that needs to be solved for a specific major segment version;
>>> let's say 1.0
>>> 3) stuff that needs to be solved by the next segment release; ie
>>> blockers.
>>>
>>> I would suggest then
>>>
>>> - Rename version 1.6 as "Oak 1.6"
>>> - Assign such version to segment versions that *have to* be solved and
>>> included by 1.6
>>> - create a "Segment 1.0" version and give it to what you think should go
>>> in 1.0. IMO Segment 1.0 does not mean Oak 1.6. It may be the same but I
>>> see the two very different.
>>>
>>> Thoughts?
>>>
>>> Davide
>>>
>>>
>
