pdfbox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hewson <j...@jahewson.com>
Subject Re: Idea: stable 2.0 versions
Date Mon, 02 Jun 2014 15:59:13 GMT
> On 2 Jun 2014, at 00:24, Maruan Sahyoun <sahyoun@fileaffairs.de> wrote:

> 
> Hi,
> 
> Maruan Sahyoun
> 
> Am 02.06.2014 um 08:59 schrieb John Hewson <john@jahewson.com>:
> 
>>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <andreas@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 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 <THausherr@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
> 

Mime
View raw message