> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <andr...@lehmi.de> wrote: > > Hi, > > Am 30.05.2014 23:13, schrieb John Hewson: >> I think the risk of creating the impression that 2.0 is stable is too high. >> The real problem >> is that 2.0 has been too long in development, there were frustrated users >> asking a year >> ago about when it would be released. > The biggest issue is, that we can't name a version stable without an official > release.
Seems like there could be some "release candidates" at some point soon... not quite yet. > >> Perhaps it’s time to push for a release of 2.0 and aim for a more frequent >> release cycle >> after that, to avoid repeating the situation where the stable and trunk >> versions are >> years apart? > +1, it's time to go for release, not tomorrow or next week, but we should > start to do some planning. > >> What is holding back 2.0? What features are we *really* holding out on? Can >> we put >> together a roadmap - our users often ask for one... > I already had a starting discussion with Maruan two weeks ago at a f2f > meeting. > > I'd like to add those changes which include api changes so what we haven't to > wait until the next major release, at least those changes which are not that > big, such as > > - solving the jempbox/xmpbox issue > - update bouncy castle > - split the pdfbox module in at least 2 modules (core and rendering) Splitting the rendering code into a module isn't really a feature... is there a higher-level goal? If so, is it achievable for a 2.0 release in the near future? > > There are some changes/improvements/bugfixes I'd like to solve as well: > > - PDFBOX-922: unicode support > - PDFBOX-62: almost done > - improve the parser concerning broken XRef-tables > - complete the recent font-improvements Yes, finally removing AWT fonts will be a huge improvement. > There some other more or less easy to solve candidates > > - enhance type safety > - remove dependencies > - .... > > There are some other things on our ideas list which should be postponed > > - enhanced parser (could maybe done without big refactorings, so that we > don't have to wait until the next major release) > - refactoring of COS-level object > - .... > > There is one important thing we have to do before releasing 2.0, an upgrade > guide including updated docs. > > We should contact press@ in preparation of the release to phrase a press > release. > > > IMHO, it could be realisitc to do a release in the summer, maybe in august. > >> -- John > > BR > Andreas Lehmkühler >> >>> On 30 May 2014, at 14:01, Tilman Hausherr <thaush...@t-online.de> wrote: >>> >>> I suggest that we come up with a concept of designating "stable versions" >>> (or "tested versions") for the trunk and put them on the homepage. A stable >>> version is one with no or only minor regressions, and/or a version that >>> committers have found to be "good". This would be for users of the 2.0 >>> version who don't want to read every discussion, and also as a hint for >>> unhappy 1.8 users. >>> >>> I suspect that other open source projects do also have rules to designate >>> stable versions, but I didn't look at them. >>> >>> Proposed rules: >>> - any committer can designate any version that is older than 24 hours as >>> stable >>> - any committer can veto any version as unstable >>> - any version that has only positive votes is mentioned on >>> https://pdfbox.apache.org/downloads.html#scm >>> - there should be up to three versions there >>> >>> Tilman >
