Hi Tilman > You labeled many a "fix version" which would mean they "must" be fixed for > 2.0. One example: PDFBOX-2402 > <https://issues.apache.org/jira/browse/PDFBOX-2402> is about a parser > improvement related to some bad PDFs that is relevant to one user only (I > will fix that one soon, I just need to create a test file, but we could as > well live without it). Another example was a color problem I had opened > (PDFBOX-2142) which is probably only relevant to rendering advertising flyers.
Yep, this is the first time we’ve tried release management with JIRA, so the starting point is that all of the issues affecting 2.0 are now scheduled to be fixed in 2.0. Obviously that’s silly, but it forces us to now examine the issues we have and actively defer them to later versions, rather than forgetting about them, or loosing them in the hundreds of old 1.8 and earlier issues which don’t apply to 2.0. Andreas - can we get a 2.1 and 3.0 version in JIRA (for breaking / non-breaking), so that the deferring can begin? These would just be estimates of course, we can always re-defer something to 2.2, etc. The idea being that issues are now actively assigned to releases, so we’re doing release management with JIRA, as well as just bug tracking. > We should name maybe 10 issues that "must" be solved before 2.0. I'm thinking > about regressions, issues were we are close to success (patterns), and issues > where somebody attached his name (with the meaning "I can fix that and I know > what has to be done"). And a short documentation about what has changed. My list of “must do’s” is fairly short: resource caching, pattern rendering, and page trees are pretty much it. Breaking API changes are really the only blockers, it’s better to wait a bit longer for 2.0 than to have say the next 5 release make breaking changes to important APIs. (Minor or niche APIs are more flexible). Cheers -- John > Tilman > > Am 11.10.2014 um 04:37 schrieb John Hewson: >> Hi All, >> >> I really want to give a better answer to this question, but the JIRA issues >> were not >> labelled with enough version-related information to allow me to simply view >> a list >> of issues which are due to be fixed in 2.0. >> >> As you’re probably aware, I went through pretty much all the issues and made >> sure >> that issues which definitely affect 2.0 had that in their "Affects >> Version/s” field. I also >> set the "Fix Version/s” for issues which are due to be fixed in 2.0, so for >> the first time >> we have a way to see which issues are due to be fixed. The end result is >> here: >> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20PDFBOX%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.0.0%20ORDER%20BY%20priority%20DESC >> >> So I can now say that we have 166 issues due to be fixed in 2.0. We might >> want to >> choose to defer some of these (we’ll need to add a “Later” version to JIRA >> to do that) >> and to maybe take a look at issues which overlap with current development >> such as >> xrefs, rendering, and parsing. >> >> Cheers >> >> -- John >> >> On 10 Oct 2014, at 11:05, John Hewson <j...@jahewson.com> wrote: >> >>> Simon, >>> >>> Andreas has the best handle on this, but off the top of my head what we >>> need is to finish >>> making breaking API changes and for the code to have been stable for a >>> while before >>> making a 2.0 release. >>> >>> Improvements and fixes which still need breaking API changes include: >>> - Pattern rendering >>> - Pages resource caching (significant memory usage issues) >>> - Font embedding (particularly TTF) >>> - Parsing (Andreas?) >>> - Page Tree (needs completely re-writing) >>> - Text extraction on Java 8 (this might end up being a breaking change >>> to the sort) >>> >>> There’s probably more, such as work on Acroforms, and we need to have much >>> better >>> example code for 2.0 due to all the changes. >>> >>> This seems like a good time to explicitly try to make sure that we have >>> JIRA issues open >>> for all outstanding tasks, so that we can track how close 2.0 is to being >>> ready. The stability >>> of the code is a pretty good indicator - we’re not there yet. >>> >>> I’m going to open some JIRA issues. Andreas, Tilman - please open issues >>> for any >>> 2.0 features which you think we need. >>> >>> Thanks >>> >>> -- John >>> >>> On 10 Oct 2014, at 08:08, Simon Steiner <simonsteiner1...@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> Could you set a target date for 2.0 release. What's missing to make a >>>> release? >>>> >>>> >>>> >>>> Thanks >>>> >> >
