Hmm,

2012/12/17 Glenn Adams <gl...@skynav.com>:
> but after a new release, the issue would effectively apply to both trunk and
> the new release, and an issue can only be associated with one version in
> JIRA;

I'm not sure if you speak about the [Affect] field, or the [Fix] field.
The former can be used with the "all" value, and IMHO is purely informative.

If you are speaking about the latter, if the fix is against the newly
created release, people should understand that it will fix the trunk
too (FOP release process is quite linear, all changes on a release
should apply to ulterior releases).

> if the issue isn't fixed by the time the release occurs, then it is unlikely
> to be fixed in the release version as much as being fixed in trunk; so that
> would argue for keeping the issue associated with trunk and not the new
> version

Well, in this case, we can rename the "trunk" entry as
"release_version" and create a new "trunk" entry at the same time,
just when a new release is decided.
We can either fix the issue against the SVN trunk (new trunk entry in
Jira), or against the SVN release branch (trunk renamed as
latest_release_name).

any thought?

> so i think i don't agree with this suggestion as i understand it
>
>
> On Mon, Dec 17, 2012 at 2:08 AM, Pascal Sancho <psancho....@gmail.com>
> wrote:
>>
>> Hi list,
>>
>> In order to keep trace about works on versions, we should use the Jira
>> feature to indicate what version is fixed.
>>
>> in almost cases, fixes are against the trunk. Since in Jira one can
>> rename the version name (see [1]), during the FOP release process (at
>> branching or tagging stage), we could rename (in Jira) the "trunk" to
>> the released version name, then create a new "trunk" entry.
>>
>> WDYT?
>>
>> [1]
>> https://confluence.atlassian.com/display/JIRA/Managing+Versions#ManagingVersions-Editingaversion%27sdetails
>>
>> 2012/12/14 Alexios Giotis <alex.gio...@gmail.com>:
>> > Hi Pascal,
>> >
>> > I noticed the "Fix Version/s" Jira field and I was tempted to update it
>> > while resolving the issue. But the only version that applies is "trunk"
>> > which is a moving target...
>> >
>> > I have not seen any guidelines related to Jira and FOP. If I miss
>> > something, please do tell me. I think, one should first decide the version
>> > number of the trunk (1.2 ? 2.0 ?) and add it to Jira. If an issue requires
>> > changes in code, then committers need to resolve it and update the "Fix"
>> > version. Finally, Jira creates "Release notes" based on this information 
>> > and
>> > one should consider if and how this affects the usage of the status.xml
>> >
>> > Alexis
>> >
>> >
>> >
>> >
>> >
>> > On 14 Dec 2012, at 17:07, Pascal Sancho <psancho....@gmail.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> before closing a bug, I think one should indicate what version its
>> >> resolution does affect.
>> >>
>> >> The goal is to easily manage changes pages in FOP website.
>> >>
>> >> 2012/12/14 Alexis Giotis (JIRA) <j...@apache.org>:
>> >>>
>> >>>     [
>> >>> https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> >>> ]
>> >>>
>> >>> Alexis Giotis closed FOP-1840.
>> >>> ------------------------------
>> >>>
>> >>>
>> >>>> [PATCH] Region-Body Column balancing incorrect if content is table
>> >>>> with header
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>>
>> >>>>                Key: FOP-1840
>> >>>>                URL: https://issues.apache.org/jira/browse/FOP-1840
>> >>>>            Project: Fop
>> >>>>         Issue Type: Improvement
>> >>>>         Components: page-master/layout
>> >>>>   Affects Versions: 1.0
>> >>>>        Environment: Operating System: All
>> >>>> Platform: PC
>> >>>>           Reporter: a.kovacs
>> >>>>           Assignee: fop-dev
>> >>>>
>> >>>> (...)

-- 
pascal

Reply via email to