Oak Segment Tar 0.0.8 release plan

[Michael Dürig <md...@apache.org>]

Hi,

I'm planning to release oak-segment-tar next Friday [1].

If there are any objections please let me know. Otherwise I'll proceed 
with the release on Friday and reschedule any open issues targeted at 
0.0.8.

Michael


[1] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20OAK%20AND%20fixVersion%20%3D%20%22Segment%20Tar%200.0.8%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Re: Oak Segment Tar 0.0.8 release plan

[Michael Dürig <md...@apache.org>]

Hi,

To follow up on this, I went ahead and removed the Segment Tar 1.0.0 
version again. Instead I spread the open issues over the versions 
Segment Tar 0.0.10 to Segment Tar 0.0.24 in a way I thought makes sense. 
Please go ahead and adjust as necessary. Later versions are 
intentionally sparsely populated to leave space for what ever issues 
come up along the way.

Michael

On 2.8.16 10:59 , Michael D�rig wrote:
>
> +1, I like this approach. It will result in some additional emails. But
> I consider this a good thing as it gives those issues we want to address
> the required visibility. Furthermore most of the noise can actually be
> avoided by setting realistic fix versions in the first place and
> checking the option to not send email updates in bulk changes.
>
> Overall I think the signal noise ratio is well balanced with this approach.
>
> Michael
>
> On 2.8.16 10:41 , Francesco Mari wrote:
>> 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 <ma...@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" <md...@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
>>>>>
>>>>>
>>>

Re: Oak Segment Tar 0.0.8 release plan

[Michael Dürig <md...@apache.org>]

+1, I like this approach. It will result in some additional emails. But 
I consider this a good thing as it gives those issues we want to address 
the required visibility. Furthermore most of the noise can actually be 
avoided by setting realistic fix versions in the first place and 
checking the option to not send email updates in bulk changes.

Overall I think the signal noise ratio is well balanced with this approach.

Michael

On 2.8.16 10:41 , Francesco Mari wrote:
> 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 <ma...@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" <md...@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
>>>>
>>>>
>>

Re: Oak Segment Tar 0.0.8 release plan

[Francesco Mari <ma...@gmail.com>]

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 <ma...@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" <md...@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
>>>
>>>
>

Re: Oak Segment Tar 0.0.8 release plan

[Francesco Mari <ma...@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" <md...@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
>>
>>
>>

Re: Oak Segment Tar 0.0.8 release plan

[Michael Dürig <md...@apache.org>]

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
>
>

Re: Oak Segment Tar 0.0.8 release plan

[Davide Giannella <da...@apache.org>]

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

Re: Oak Segment Tar 0.0.8 release plan

[Alex Parvulescu <al...@gmail.com>]

Hi,

My preference would be for setting a fix version, whatever that may be (I'd
go for '1.0' same as Marcel's proposal). Anything other than that (labels,
resolve as later or assignee) would only overload other Jira terms and make
things confusing all around.

best,
alex


On Wed, Jul 27, 2016 at 6:17 PM, Marcel Reutegger <mr...@adobe.com>
wrote:

> Hi,
>
> On 27/07/16 17:57, Michael Dürig wrote:
>
>> 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.
>>
>
> Why not use a "Segment Tar 1.0" version for issues you intend to resolve
> for Oak 1.6? Assuming that we want to include a 1.0 version for the Oak
> 1.6 release.
>
> Otherwise, no fix version until you resolve an issue would work for me
> as well ;)
>
> Regards
>  Marcel
>

Re: Oak Segment Tar 0.0.8 release plan

[Marcel Reutegger <mr...@adobe.com>]

Hi,

On 27/07/16 17:57, Michael D�rig wrote:
> 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.

Why not use a "Segment Tar 1.0" version for issues you intend to resolve
for Oak 1.6? Assuming that we want to include a 1.0 version for the Oak
1.6 release.

Otherwise, no fix version until you resolve an issue would work for me
as well ;)

Regards
  Marcel

Re: Oak Segment Tar 0.0.8 release plan

[Michael Dürig <md...@apache.org>]

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).

WDYT?

Michael


On 27.7.16 4:58 , Michael D�rig wrote:
>
> I actually used 1.6 so far for all issues that should be resolved once
> Oak 1.6 is released. We can replace this with any other mechanism (maybe
> a version Segment Tar 1.0.0) but I'd like something to identify  issues
> we target in this Oak release cycle.
>
> Michael
>
> On 27.7.16 4:50 , Francesco Mari wrote:
>> I would better remove the fix version completely. The main difference
>> between oak-segment-tar and the rest of Oak is that there is no final
>> cut for this bundle and a version like 1.6 makes very little sense to
>> oak-segment-tar. If an issue is to be solved at some unspecified point
>> in the future and there is no well defined commitment towards the very
>> next version, I would just leave the fix version empty.
>>
>> 2016-07-27 16:21 GMT+02:00 Marcel Reutegger <mr...@adobe.com>:
>>> Hi,
>>>
>>> On 27/07/16 16:13, Michael D�rig wrote:
>>>>
>>>> I'm planning to release oak-segment-tar next Friday [1].
>>>>
>>>> If there are any objections please let me know. Otherwise I'll proceed
>>>> with the release on Friday and reschedule any open issues targeted at
>>>> 0.0.8.
>>>
>>>
>>> No objections, but one suggestion.
>>>
>>> With every oak-segment-tar release a rather large number of issues are
>>> rescheduled. Would it make sense to adopt a similar process of assigning
>>> fix versions as we do with the other modules? Initially a issue would
>>> have a fix version of 1.0 and once resolved the fix version is set to
>>> the upcoming release version.
>>>
>>> Regards
>>>  Marcel

Re: Oak Segment Tar 0.0.8 release plan

[Michael Dürig <md...@apache.org>]

I actually used 1.6 so far for all issues that should be resolved once 
Oak 1.6 is released. We can replace this with any other mechanism (maybe 
a version Segment Tar 1.0.0) but I'd like something to identify  issues 
we target in this Oak release cycle.

Michael

On 27.7.16 4:50 , Francesco Mari wrote:
> I would better remove the fix version completely. The main difference
> between oak-segment-tar and the rest of Oak is that there is no final
> cut for this bundle and a version like 1.6 makes very little sense to
> oak-segment-tar. If an issue is to be solved at some unspecified point
> in the future and there is no well defined commitment towards the very
> next version, I would just leave the fix version empty.
>
> 2016-07-27 16:21 GMT+02:00 Marcel Reutegger <mr...@adobe.com>:
>> Hi,
>>
>> On 27/07/16 16:13, Michael D�rig wrote:
>>>
>>> I'm planning to release oak-segment-tar next Friday [1].
>>>
>>> If there are any objections please let me know. Otherwise I'll proceed
>>> with the release on Friday and reschedule any open issues targeted at
>>> 0.0.8.
>>
>>
>> No objections, but one suggestion.
>>
>> With every oak-segment-tar release a rather large number of issues are
>> rescheduled. Would it make sense to adopt a similar process of assigning
>> fix versions as we do with the other modules? Initially a issue would
>> have a fix version of 1.0 and once resolved the fix version is set to
>> the upcoming release version.
>>
>> Regards
>>  Marcel

Re: Oak Segment Tar 0.0.8 release plan

[Francesco Mari <ma...@gmail.com>]

I would better remove the fix version completely. The main difference
between oak-segment-tar and the rest of Oak is that there is no final
cut for this bundle and a version like 1.6 makes very little sense to
oak-segment-tar. If an issue is to be solved at some unspecified point
in the future and there is no well defined commitment towards the very
next version, I would just leave the fix version empty.

2016-07-27 16:21 GMT+02:00 Marcel Reutegger <mr...@adobe.com>:
> Hi,
>
> On 27/07/16 16:13, Michael Dürig wrote:
>>
>> I'm planning to release oak-segment-tar next Friday [1].
>>
>> If there are any objections please let me know. Otherwise I'll proceed
>> with the release on Friday and reschedule any open issues targeted at
>> 0.0.8.
>
>
> No objections, but one suggestion.
>
> With every oak-segment-tar release a rather large number of issues are
> rescheduled. Would it make sense to adopt a similar process of assigning
> fix versions as we do with the other modules? Initially a issue would
> have a fix version of 1.0 and once resolved the fix version is set to
> the upcoming release version.
>
> Regards
>  Marcel

Re: Oak Segment Tar 0.0.8 release plan

[Marcel Reutegger <mr...@adobe.com>]

Hi,

On 27/07/16 16:13, Michael D�rig wrote:
> I'm planning to release oak-segment-tar next Friday [1].
>
> If there are any objections please let me know. Otherwise I'll proceed
> with the release on Friday and reschedule any open issues targeted at
> 0.0.8.

No objections, but one suggestion.

With every oak-segment-tar release a rather large number of issues are
rescheduled. Would it make sense to adopt a similar process of assigning
fix versions as we do with the other modules? Initially a issue would
have a fix version of 1.0 and once resolved the fix version is set to
the upcoming release version.

Regards
  Marcel