Idea: stable 2.0 versions
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
Re: Idea: stable 2.0 versions
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. 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? 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... -- John On 30 May 2014, at 14:01, Tilman Hausherr 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 >
Re: Idea: stable 2.0 versions
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 - update bouncy castle - split the pdfbox module in at least 2 modules (core and rendering) 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 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 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
Re: Idea: stable 2.0 versions
Hi Am 01.06.2014 um 15:03 schrieb Andreas Lehmkuehler : > 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 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 >>> >> >> >
Re: Idea: stable 2.0 versions
Am 01.06.2014 15:46, schrieb Maruan Sahyoun: > >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. Here are the ones I know about: old => new PDXObjectForm => PDFormXObject PDXObjectImage => PDImageXObject PDPage.convertToImage() => PDFRenderer(PDDocument).renderImage() PDXObjectImage.getRGBImage() => PDImageXObject.getImage() => PDFPrinter(PDDocument, ).print(PDDocument,PrinterJob, ...)
Re: Idea: stable 2.0 versions
Hi Am 01.06.2014 um 18:51 schrieb Tilman Hausherr : > Am 01.06.2014 15:46, schrieb Maruan Sahyoun: >>> > >>> >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. >> > > Here are the ones I know about: > > old => new > > PDXObjectForm => PDFormXObject > PDXObjectImage => PDImageXObject > PDPage.convertToImage() => PDFRenderer(PDDocument).renderImage() > PDXObjectImage.getRGBImage() => PDImageXObject.getImage() > > => PDFPrinter(PDDocument, ).print(PDDocument,PrinterJob, …) AFAIK this was PDDocument.print()
Re: Idea: stable 2.0 versions
> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler 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 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 >
Re: Idea: stable 2.0 versions
Hi, Maruan Sahyoun Am 02.06.2014 um 08:59 schrieb John Hewson : >> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler 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 requests for PDFBox on Android where most of awt is not available. > >> >> 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 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 >>
Re: Idea: stable 2.0 versions
Am 01.06.2014 19:57, schrieb Maruan Sahyoun: Hi Am 01.06.2014 um 18:51 schrieb Tilman Hausherr : Am 01.06.2014 15:46, schrieb Maruan Sahyoun: 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. Here are the ones I know about: old => new PDXObjectForm => PDFormXObject PDXObjectImage => PDImageXObject PDPage.convertToImage() => PDFRenderer(PDDocument).renderImage() PDXObjectImage.getRGBImage() => PDImageXObject.getImage() => PDFPrinter(PDDocument, ).print(PDDocument,PrinterJob, …) AFAIK this was PDDocument.print() Yes indeed. Got another: 1.8: public void processStream( PDPage aPage, PDResources resources, COSStream cosStream ) public void processSubStream(PDPage aPage, PDResources resources, COSStream cosStream) 2.0: public void processStream(PDResources resources, COSStream cosStream, PDRectangle drawingSize, int rotation) public void processSubStream(PDResources resources, COSStream cosStream)
Re: Idea: stable 2.0 versions
Andreas, Has there been discussion of PDFBOX-1586 as yet? This is the second bug for which we are having to maintain an internal fork of PDFBox for. I do not have the knowledge necessary to resolve it myself so I'm rather hanging on the core developers I'm afraid. Thanks, James On 2 June 2014 09:11, Tilman Hausherr wrote: > Am 01.06.2014 19:57, schrieb Maruan Sahyoun: > > Hi >> >> Am 01.06.2014 um 18:51 schrieb Tilman Hausherr : >> >> Am 01.06.2014 15:46, schrieb Maruan Sahyoun: >>> 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. Here are the ones I know about: >>> >>> old => new >>> >>> PDXObjectForm => PDFormXObject >>> PDXObjectImage => PDImageXObject >>> PDPage.convertToImage() => PDFRenderer(PDDocument).renderImage() >>> PDXObjectImage.getRGBImage() => PDImageXObject.getImage() >>> >>> => PDFPrinter(PDDocument, ).print(PDDocument,PrinterJob, …) >>> >> AFAIK this was PDDocument.print() >> > > Yes indeed. > > Got another: > > 1.8: > public void processStream( PDPage aPage, PDResources resources, COSStream > cosStream ) > public void processSubStream(PDPage aPage, PDResources resources, > COSStream cosStream) > > 2.0: > public void processStream(PDResources resources, COSStream cosStream, > PDRectangle drawingSize, int rotation) > public void processSubStream(PDResources resources, COSStream cosStream) > > > >
Re: Idea: stable 2.0 versions
Pl dont put in ur cc. On Sat, May 31, 2014 at 2:31 AM, Tilman Hausherr 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 > >
Re: Idea: stable 2.0 versions
> On 2 Jun 2014, at 00:24, Maruan Sahyoun wrote: > > Hi, > > Maruan Sahyoun > > Am 02.06.2014 um 08:59 schrieb John Hewson : > >>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler 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 requests for PDFBox on Android where most of awt is not available. So the ultimate goal is to have an Android release for 2.0, who's going to do this? AWT is very deeply integrated into PD (e.g. colour spaces, images) and also FontBox (paths). I think a workable plan for removing it is much harder than it looks. > >> >>> >>> 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 I'm thinking of taking a look at XRefs. >>> - 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) Yeah, let's just makes sure the public API is nice and tight, then we can refactor the internals at will later. >>> - 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 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 >
Re: Idea: stable 2.0 versions
Hi Am 02.06.2014 um 17:59 schrieb John Hewson : >> On 2 Jun 2014, at 00:24, Maruan Sahyoun wrote: > >> >> Hi, >> >> Maruan Sahyoun >> >> Am 02.06.2014 um 08:59 schrieb John Hewson : >> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler 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 requests for PDFBox on Android where most of awt is not available. > > So the ultimate goal is to have an Android release for 2.0, who's going to do > this? AWT is very deeply integrated into PD (e.g. colour spaces, images) and > also FontBox (paths). I think a workable plan for removing it is much harder > than it looks. I don’t think and didn’t want to say that an Android release shall be done for 2.0. Only wanted to provide feedback why rendering might be on it’s own module as per Andreas input. > >> >>> 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 > > I'm thinking of taking a look at XRefs. > - 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) > > Yeah, let's just makes sure the public API is nice and tight, then we can > refactor the internals at will later. > - 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 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 >>
Re: Idea: stable 2.0 versions
Hi, Am 02.06.2014 18:46, schrieb Maruan Sahyoun: Hi Am 02.06.2014 um 17:59 schrieb John Hewson : On 2 Jun 2014, at 00:24, Maruan Sahyoun wrote: Hi, Maruan Sahyoun Am 02.06.2014 um 08:59 schrieb John Hewson : On 1 Jun 2014, at 06:03, Andreas Lehmkuehler 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 requests for PDFBox on Android where most of awt is not available. So the ultimate goal is to have an Android release for 2.0, who's going to do this? AWT is very deeply integrated into PD (e.g. colour spaces, images) and also FontBox (paths). I think a workable plan for removing it is much harder than it looks. I don’t think and didn’t want to say that an Android release shall be done for 2.0. Only wanted to provide feedback why rendering might be on it’s own module as per Andreas input. Just to avoid misunderstandings. The idea is to have the option to omit certain parts of PDFBox if those are not needed, e.g. for serverside indexing one don't need rendering capabilities. As a side effect the remaining (core) part would be more android friendly as it doesn't contains that much (in a perfect world no) AWT stuff. The same is maybe true for AWS, GAE or similar environments. BR Andreas Lehmkühler
Re: Idea: stable 2.0 versions
> On 10 Jun 2014, at 23:02, Andreas Lehmkuehler wrote: > > Hi, > > Am 02.06.2014 18:46, schrieb Maruan Sahyoun: >> Hi >> >> Am 02.06.2014 um 17:59 schrieb John Hewson : >> On 2 Jun 2014, at 00:24, Maruan Sahyoun wrote: >>> Hi, Maruan Sahyoun Am 02.06.2014 um 08:59 schrieb John Hewson : >> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler 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 requests for PDFBox on Android where most of awt is not available. >>> >>> So the ultimate goal is to have an Android release for 2.0, who's going to >>> do this? AWT is very deeply integrated into PD (e.g. colour spaces, images) >>> and also FontBox (paths). I think a workable plan for removing it is much >>> harder than it looks. >> >> I don’t think and didn’t want to say that an Android release shall be done >> for 2.0. Only wanted to provide feedback why rendering might be on it’s own >> module as per Andreas input. > Just to avoid misunderstandings. The idea is to have the option to omit > certain parts of PDFBox if those are not needed, e.g. for serverside indexing > one don't need rendering capabilities. As a side effect the remaining (core) > part would be more android friendly as it doesn't contains that much (in a > perfect world no) AWT stuff. The same is maybe true for AWS, GAE or similar > environments. GAE forbids even importing classes from AWT, so if there's even a single Rectangle or Point in core then it won't work. Likewise if core depends on FontBox then that will also not be able to use GeneralPath, AffineTranaform, etc. Android is more flexible but it has no native AWT implementation. -- John
Re: Idea: stable 2.0 versions
Hi, > John Hewson hat am 12. Juni 2014 um 09:14 geschrieben: > > > > On 10 Jun 2014, at 23:02, Andreas Lehmkuehler wrote: > > > > Hi, > > > > Am 02.06.2014 18:46, schrieb Maruan Sahyoun: > >> Hi > >> > >> Am 02.06.2014 um 17:59 schrieb John Hewson : > >> > On 2 Jun 2014, at 00:24, Maruan Sahyoun wrote: > >>> > > Hi, > > Maruan Sahyoun > > Am 02.06.2014 um 08:59 schrieb John Hewson : > > >> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler wrote: > >> > >> Hi, > >> > >> Am 30.05.2014 23:13, schrieb John Hewson: SNIP > There are requests for PDFBox on Android where most of awt is not > available. > >>> > >>> So the ultimate goal is to have an Android release for 2.0, who's going to > >>> do this? AWT is very deeply integrated into PD (e.g. colour spaces, > >>> images) and also FontBox (paths). I think a workable plan for removing it > >>> is much harder than it looks. > >> > >> I don’t think and didn’t want to say that an Android release shall be done > >> for 2.0. Only wanted to provide feedback why rendering might be on it’s own > >> module as per Andreas input. > > Just to avoid misunderstandings. The idea is to have the option to omit > > certain parts of PDFBox if those are not needed, e.g. for serverside > > indexing one don't need rendering capabilities. As a side effect the > > remaining (core) part would be more android friendly as it doesn't contains > > that much (in a perfect world no) AWT stuff. The same is maybe true for AWS, > > GAE or similar environments. > > GAE forbids even importing classes from AWT, so if there's even a single > Rectangle or Point in core then it won't work. Likewise if core depends on > FontBox then that will also not be able to use GeneralPath, AffineTranaform, > etc. Android is more flexible but it has no native AWT implementation. That's why I say android friendly. If we split up the code base, it would be easier to figure out which parts of a module (which isn't directly connected to the rendering) have to be reimplemented to avoid AWT to support android, AWS, GAE and whatever is needed/wanted. Even for those who are not that familiar with the code base at all. I'd not say that we should do that at all costs, but maybe others are interested. Let's see if it is possible without to much effort. > -- John BR Andreas Lehmkühler
Re: Idea: stable 2.0 versions
On 12 Jun 2014, at 00:43, Andreas Lehmkühler wrote: > Hi, > >> John Hewson hat am 12. Juni 2014 um 09:14 geschrieben: >> >> >>> On 10 Jun 2014, at 23:02, Andreas Lehmkuehler wrote: >>> >>> Hi, >>> >>> Am 02.06.2014 18:46, schrieb Maruan Sahyoun: Hi Am 02.06.2014 um 17:59 schrieb John Hewson : >> On 2 Jun 2014, at 00:24, Maruan Sahyoun wrote: > >> >> Hi, >> >> Maruan Sahyoun >> >> Am 02.06.2014 um 08:59 schrieb John Hewson : >> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler wrote: Hi, Am 30.05.2014 23:13, schrieb John Hewson: > > SNIP > >> There are requests for PDFBox on Android where most of awt is not >> available. > > So the ultimate goal is to have an Android release for 2.0, who's going to > do this? AWT is very deeply integrated into PD (e.g. colour spaces, > images) and also FontBox (paths). I think a workable plan for removing it > is much harder than it looks. I don’t think and didn’t want to say that an Android release shall be done for 2.0. Only wanted to provide feedback why rendering might be on it’s own module as per Andreas input. >>> Just to avoid misunderstandings. The idea is to have the option to omit >>> certain parts of PDFBox if those are not needed, e.g. for serverside >>> indexing one don't need rendering capabilities. As a side effect the >>> remaining (core) part would be more android friendly as it doesn't contains >>> that much (in a perfect world no) AWT stuff. The same is maybe true for AWS, >>> GAE or similar environments. >> >> GAE forbids even importing classes from AWT, so if there's even a single >> Rectangle or Point in core then it won't work. Likewise if core depends on >> FontBox then that will also not be able to use GeneralPath, AffineTranaform, >> etc. Android is more flexible but it has no native AWT implementation. > That's why I say android friendly. If we split up the code base, it would be > easier to figure out which parts of a module (which isn't directly connected > to > the rendering) have to be reimplemented to avoid AWT to support android, AWS, > GAE and whatever is needed/wanted. Even for those who are not that familiar > with > the code base at all. I'd not say that we should do that at all costs, but > maybe > others are interested. > > Let's see if it is possible without to much effort. Ok, so we’re trying to facilitate contributions, but there isn’t a fixed goal that we must achieve for 2.0 - that’s ok. — John
