On 23/07/2014 17:55, Vincent Hennebert wrote:
On 23/07/14 12:05, Manuel Mall wrote:
Hi,
Just a thought on this topic:
Changing the minimum JDK requirement is quite a big step. If FOP 2.0
is released with JDK 1.5 minimum requirements you probably don't want
to change this until you get to Fop 3.0. Users would typically expect
2.x releases to maintain this sort of major backwards compatibility
characteristic. As a user I certainly would be upset if let's say a
few month after 2.0 release 2.1 comes out with minor enhancements and
bug fixes and it suddenly increases the minimum JDK level because a
JDK 1.6 dependency was introduced in trunk and I have Fop 2.0 running
in a 1.5 production environment that can't be changed in a hurry.
So, in my opinion declare Fop 2.0 as dependant on 1.6 now (even if it
technically it isn't) or stick around with 1.5 until the next major
release.
Thanks for your input Manuel, that makes sense. I guess I’ll advertise
FOP to be dependent on 1.6 then.
+1
Thanks,
Chris
Cheers
Manuel
Vincent
-----Original Message-----
From: Vincent Hennebert [mailto:vhenneb...@gmail.com]
Sent: Wednesday, 23 July 2014 5:16 PM
To: general@xmlgraphics.apache.org
Subject: Re: Releasing XGC, Batik and FOP
Hi Chris,
On 23/07/14 10:06, Chris Bowditch wrote:
Hi Vincent,
On 17/07/2014 12:59, Vincent Hennebert wrote:
Hi All,
(Moving to general@ as not only FOP is involved.)
I should be able to spare some cycles over the next few weeks to do a
release of XGC, Batik and FOP. The new versions would be:
• XGC 1.6
• Batik 1.8
• FOP 2.0
The minimum supported JRE for all projects would be 1.5.
I thought in previous discussions the PMC approved the upgrade to Java
6? I'm not sure if anyone has committed any 1.6 specific changes
between now and then, but if they have then a final release based on
1.5 won't be possible.
Yes, it’s agreed that 1.6 features can now be introduced to trunk.
But IIC that hasn’t happened yet. So if I am able to build the
release with a 1.5 JDK, I might as well do so. Otherwise we’ll just
increase the minimum requirement in the release announcement.
Here’s my view: Branches would be created from the trunks as of now
+ whatever has been committed at the time they are created. That
+ means
that no existing issue would be required to be solved first (and that
all of the open FOP issues currently rated as blocker and critical
can be downgraded to major).
If anybody thinks that some issues/features ought to be
fixed/integrated in one of the projects before the releases, please
mention it now so that we can discuss it. At any rate I won’t start
anything before Wed 30th July.
Which version of pdfbox will users of font merging feature or
pdf-plugin be expected to use? My understanding is that its a 2.0
snapshot currently, so we might need to wait until PDFbox release
that version, before doing the release.
AFAIU FOP only depends on FontBox 1.8.5, so it can be released now.
If users want to use the PDF Images plug-in, then that’s another story.
They would have to use a snapshot version of FontBox instead, as well
as the plug-in for that matter.
But since that plug-in has never been released, and is not documented
on the website, I doubt that there are many people outside of the
core developer group who are using it.
FOP doesn’t depend on the plug-in to deliver its core functionality
anyway, so it can be released independently.
We could (should) talk about creating a release and a website for the
plug-in. If the code before the FontMerging change still is
compatible with FOP’s current trunk, then it would have only released
dependencies and we could deliver a version that would remain
compatible with FOP 2.0. But I’m not sure I’ll have the time to do
all the checks and the work.
Vincent
Any comment, suggestion?
Thanks,
Vincent
Thanks,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: general-h...@xmlgraphics.apache.org
