Hi Am 01.06.2014 um 15:03 schrieb Andreas Lehmkuehler <[email protected]>:
> 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. > >> 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 could handle that > - update bouncy castle > - split the pdfbox module in at least 2 modules (core and rendering) would break into pdfbox-core (parsing and COS), pdfbox-pd (PD model) and pdfbox-rendering. > > There are some changes/improvements/bugfixes I'd like to solve as well: > > - PDFBOX-922: unicode support one of the most important missing basic features affecting forms handling, updating a pdf with non ISO chars ….. > - PDFBOX-62: almost done > - improve the parser concerning broken XRef-tables > - complete the recent font-improvements > > 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) +1 to postpone it (haven’t go any feedback on the lexer yet). At least it could be done wo affecting the PD model. > - refactoring of COS-level object +1 to postpone it as this should be done together with the parsing > - .... > > There is one important thing we have to do before releasing 2.0, an upgrade > guide including updated docs. could handle that. Would need some input about major changes as a starting point as I din’t follow all breaking changes. > > 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 WRT a roadmap I’d think it would be very good to come up with one but that would mean to agree on a set of features/changes upfront for a specific release. Don’t know if that is doable. E.g. a lot of the new/improved functionality is around rendering which is a very important functionality as this is a very common use case. On the other hand that hasn’t been on the ideas page. > > BR > Andreas Lehmkühler >> >> On 30 May 2014, at 14:01, Tilman Hausherr <[email protected]> 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 >>> >> >> >
