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 <mreut...@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
