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 <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
