You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2006/06/18 12:53:14 UTC
When to release 1.0?
I just realized we should think about the right moment to release 1.0. I
guess the number of fixed bugs would suggest a new release rather sooner
than later. I originally thought about going for an ApacheCon release
but I didn't have enough time. Now, Vincent is working on floats and the
requirement for changing IPD between pages gets more important (see
fop-users and one of my clients would like to see an increase in
priority). However, both points may have a serious impact on the layout
engine especially since both feature have a certain conflict potential
for the page breaking approach. Manuel and I have chatted over Skype
about this and Manuel will also look a little deeper into the issue. I
suspect both items will require substantial changes in the layout engine
which are probably better done after the next release (or on a separate
branch). I think it would be good to do the 1.0 release some time in
July, if possible.
WDYT?
Jeremias Maerki
Re: When to release 1.0?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I've updated the ReleasePlanning page. ATM, I've simply changed it to
what I read from this thread. Please, everyone, help sorting out the
details so we can decide where to go.
On 19.06.2006 10:31:15 Jeremias Maerki wrote:
<snip/>
> > So maybe we need a feature freeze and bug fixing period?
>
> Not only that. We need a Wiki page listing all issues everyone wants to
> see fixed/handled before a 1.0 release. We can then decide on which
> subset we are really going to process. Otherwise, we won't finish before
> 2007.
>
> There was http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning. I
> suggest we streamline that page and bring it up to date again, so we
> have a single point to look at to track the progress towards 1.0.
<snip/>
Jeremias Maerki
Re: When to release 1.0?
Posted by Web Maestro Clay <th...@gmail.com>.
On Jun 19, 2006, at 2:37 AM, Chris Bowditch wrote:
> Jeremias Maerki wrote:
>> On 18.06.2006 20:50:31 Simon Pepping wrote:
>>> So maybe we need a feature freeze and bug fixing period?
>> Not only that. We need a Wiki page listing all issues everyone
>> wants to
>> see fixed/handled before a 1.0 release. We can then decide on which
>> subset we are really going to process. Otherwise, we won't finish
>> before
>> 2007.
>
> Agreed.
>
>> There was http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning. I
>> suggest we streamline that page and bring it up to date again, so we
>> have a single point to look at to track the progress towards 1.0.
>
> Good idea.
>
>> With all the feedback so far I think it's better to do another 0.x
>> round
>> soon, i.e. FOP 0.93. We've already communicated that 0.92 would be
>> the
>> last before 1.0 but if there's so much hesitation for 1.0 we'd
>> better do
>> a 0.93 first. Beta tag? I wouldn't. Disappointed? Probably. Sorry. I
>> guess I grew too attached to this thing.
>
> Removing the beta tag will help me persuade more folks to use FOP
> 0.9x. Going to 1.0 will make this job easier still. Although I
> can't help but think we should fix the changing IPD problem first
> as well :(
>
> Chris
I was also thinking it would be good to identify some 'pre-
requisites' for a launch in a wiki. Testing on large documents would
be great as well. In any case, even after we release, people don't
have to switch (they can still use 0.20.5 if they like!).
My preference would be to do a release sooner (in July if possible).
Once we do a release, we'll have a lot more beta^H^H^H^H early
adopters who can help us iron out the details (BTW, I'm very
impressed with the progress the FOP-DEV team has made!).
Web Maestro Clay
the.webmaestro@gmail.com
My religion is simple. My religion is kindness.
-- HH Dalai Lama of Tibet
Re: When to release 1.0?
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
> On 18.06.2006 20:50:31 Simon Pepping wrote:
<snip/>
>>So maybe we need a feature freeze and bug fixing period?
>
>
> Not only that. We need a Wiki page listing all issues everyone wants to
> see fixed/handled before a 1.0 release. We can then decide on which
> subset we are really going to process. Otherwise, we won't finish before
> 2007.
Agreed.
>
> There was http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning. I
> suggest we streamline that page and bring it up to date again, so we
> have a single point to look at to track the progress towards 1.0.
Good idea.
>
> With all the feedback so far I think it's better to do another 0.x round
> soon, i.e. FOP 0.93. We've already communicated that 0.92 would be the
> last before 1.0 but if there's so much hesitation for 1.0 we'd better do
> a 0.93 first. Beta tag? I wouldn't. Disappointed? Probably. Sorry. I
> guess I grew too attached to this thing.
Removing the beta tag will help me persuade more folks to use FOP 0.9x.
Going to 1.0 will make this job easier still. Although I can't help but
think we should fix the changing IPD problem first as well :(
Chris
Re: When to release 1.0?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 18.06.2006 20:50:31 Simon Pepping wrote:
> On Sun, Jun 18, 2006 at 07:26:00PM +0800, Manuel Mall wrote:
> > On Sunday 18 June 2006 18:53, Jeremias Maerki wrote:
> > > look a little deeper into the issue. I suspect both items will
> > > require substantial changes in the layout engine which are probably
> > > better done after the next release (or on a separate branch). I think
> > > it would be good to do the 1.0 release some time in July, if
> > > possible.
>
> That sounds OK.
>
> > Judging the quality of the FOP trunk code base is much harder. For
> > example, we still get reports of NPEs and AIOOBs. We don't know how it
> > will perform when asked to render 1000's of documents a day. We don't
> > know if there are any memory leaks. We don't know if its thread
> > safe....
>
> But this is indeed a problem. Valid documents should not throw runtime
> exceptions. They may encounter a FOP not-implemented exception.
That's a noble goal, but there are limits to what degree you can
accomplish that. We have to build test cases from all these reports to
have regression tests and then fix them. There are also bigger problems
like the exception when fo:wrapper is used around block-level content.
That's the main reason why the XSL 1.1 test suite is failing in so many
places.
> So maybe we need a feature freeze and bug fixing period?
Not only that. We need a Wiki page listing all issues everyone wants to
see fixed/handled before a 1.0 release. We can then decide on which
subset we are really going to process. Otherwise, we won't finish before
2007.
There was http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning. I
suggest we streamline that page and bring it up to date again, so we
have a single point to look at to track the progress towards 1.0.
With all the feedback so far I think it's better to do another 0.x round
soon, i.e. FOP 0.93. We've already communicated that 0.92 would be the
last before 1.0 but if there's so much hesitation for 1.0 we'd better do
a 0.93 first. Beta tag? I wouldn't. Disappointed? Probably. Sorry. I
guess I grew too attached to this thing.
Jeremias Maerki
Re: When to release 1.0?
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Sun, Jun 18, 2006 at 07:26:00PM +0800, Manuel Mall wrote:
> On Sunday 18 June 2006 18:53, Jeremias Maerki wrote:
> > look a little deeper into the issue. I suspect both items will
> > require substantial changes in the layout engine which are probably
> > better done after the next release (or on a separate branch). I think
> > it would be good to do the 1.0 release some time in July, if
> > possible.
That sounds OK.
> Judging the quality of the FOP trunk code base is much harder. For
> example, we still get reports of NPEs and AIOOBs. We don't know how it
> will perform when asked to render 1000's of documents a day. We don't
> know if there are any memory leaks. We don't know if its thread
> safe....
But this is indeed a problem. Valid documents should not throw runtime
exceptions. They may encounter a FOP not-implemented exception.
So maybe we need a feature freeze and bug fixing period?
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: When to release 1.0?
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
<snip/>
>>Please can you say where you think 0.92beta is behind 0.20.5? The only
>>issue that I'm aware of is the change of IPD mid-page-sequence.
>
>
> I've listed them in http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning
> I was a little surprised. It's not just 2 or 3 items.
>
Thanks for that. It isnt too bad IMHO. Although I remembered another one
you missed off. I've added some feedback on the other issues in the Wiki.
Chris
Re: When to release 1.0?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 19.06.2006 11:35:18 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
> > On 18.06.2006 13:26:00 Manuel Mall wrote:
>
> <snip/>
>
> >>
> >>Calling a release 1.0 is IMO quite a significant step which shouldn't
> >>been taken lightly. What we are saying in doing so is: Here is
> >>something we believe is ready for production use.
> >
> >
> > Yes, but neither should we put off a 1.0 for much longer. Having a 0.x
> > version number is a big disadvantange. OTOH, when I released Barcode4J
> > 1.0 it was almost too perfect. Almost no serious problems and also
> > almost no third-party patches. No community building. One-man show. :-(
>
> I don't think you can compare Barcode4J to FOP. FOP is a much bigger and
> more complex system.
Sure, it's bigger, but my point was about community building. And that
doesn't have so much to do with the size of a project. The question is:
What makes someone decide to help out in a project and send patches?
That's a very important question we have to ask ourselves. We still need
to attract new people. For example, all those tool producers lurking on
this list and/or using Apache FOP in their products. I'm in contact with
some of them. Pretty much everyone says they are interested but still
most of them hold back. Some because they are still stuck with 0.20.5
(many have customized 0.20.5 versions). Frankly, I'm stumped as to why
they don't even give their opinions where they would like to see FOP
head. I'd like to find out what we can do to encourage them to join us.
So far, I have no recipe. At least, I'm happy to have some supporters
who enabled me to allocate so much time to FOP in the last 18 months,
even if some of them choose to stay in the background. Still, given
FOP's popularity and the progress we made in the past months, I'm
surprised we don't get more supporters. But as you say, a 1.0 will
certainly have a big boost in this direction. What else can we do?
At this point, I want to say a big thank-you to the Swiss Federal
Insitute of Intellectual Property which supported me to fix several bugs
and to implement some layout enhancements and support for PDF/A-1b,
PDF/X-3:2003, fixed-width spaces and kerning. And of course, a huge
thank-you to my biggest supporter who enabled me to help bring FOP to
where it is today!
<snip/>
> Please can you say where you think 0.92beta is behind 0.20.5? The only
> issue that I'm aware of is the change of IPD mid-page-sequence.
I've listed them in http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning
I was a little surprised. It's not just 2 or 3 items.
<snip/>
Jeremias Maerki
Re: When to release 1.0?
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
> On 18.06.2006 13:26:00 Manuel Mall wrote:
<snip/>
>>
>>Calling a release 1.0 is IMO quite a significant step which shouldn't
>>been taken lightly. What we are saying in doing so is: Here is
>>something we believe is ready for production use.
>
>
> Yes, but neither should we put off a 1.0 for much longer. Having a 0.x
> version number is a big disadvantange. OTOH, when I released Barcode4J
> 1.0 it was almost too perfect. Almost no serious problems and also
> almost no third-party patches. No community building. One-man show. :-(
I don't think you can compare Barcode4J to FOP. FOP is a much bigger and
more complex system.
>
> In 2005 we saw an increase in interest to help with the development of
> FOP. This year I get the impression that this wave is ebbing away again.
> I wonder why. But I also wonder how we can improve that. A 1.0 release
> would be a good signal. Does a 1.0 have to be perfect? M$ usually needs
> at least two service packs to reach a usable level for their software.
> Poor excuse, I know, but still, it somehow applies. And frankly, the
> quality level we can automatically maintain with our test suite today is
> quite remarkable. That said, I believe FOP is ready for production use
> now.
I agree with your observations. A lot of people I have spoke to are very
negative on FOP because of the way it is marked as beta and with a
version number < 1.0. I have been trying to persuade more people to use
it, but whilst it still has a beta tag I am facing an up hill battle.
FOP will only get more people willing to contribute to its development
when it gets more users and it will only get more users once we do a 1.0
release and send out the message that FOP is ready for production use.
It will certainly help if the beta tag is removed for the next release.
>
>
>>So from my perspective we need to answer two questions in the positive:
>>
>>A) Does this version of FOP deliver a sufficient degree of compliance to
>>the XSL-FO spec to be considered ready for production use?
>
>
> For which user? The degree of compliance the various user groups need is
> quite different. For the business documents I've worked with so far in
> my FO experience I wouldn't hesitate to use FOP Trunk in production.
> Were I someone who needs to create book-style documents I'd probably
> say: Hey, why should I use this crap if it doesn't even handle
> page-number-citations correctly in a table of contents? What I want to
> say is that you can't make a software usable to the same level for
> everyone. There are users out there who still think XSL-FO is the right
> tech to create large tabular reports with hundreds of pages. I wonder
> why some managers still think they need these reports. (sorry, getting
> carried away)
I agree with your observations here too.
>
> Judging FOP Trunk by the level of compliance of 0.20.5 is certainly one
> way of answering this question but it is not necessarily the only way.
>
>
>>B) Does it deliver those features with the required level of quality
>>expected from an ASF product?
>
>
> We've had over half a year of bugfixing and stabilization and we have a
> very precious test suite which helps keeping the number of regressions
> very low. Only the renderers are not really covered by automated tests
> because that's quite difficult to do right with a good ROI. That, combined
> with the feedback from the community, tells me we're good enough. IMHO,
> of course.
>
>
>>How can we answer those questions?
>>
>>For A) IMO it is easy. The old FOP version (0.20.5) is used in many
>>production environments. If we meet or exceed compliance compared to
>>0.20.5 I would give A) a tick. However, ATM we are still behind 0.20.5
>>in some areas although well ahead in many others.
Please can you say where you think 0.92beta is behind 0.20.5? The only
issue that I'm aware of is the change of IPD mid-page-sequence.
>
>
> Ok, so we need a Wiki page where we can track the progress for the view
> on FOP Trunk. And we need to agree on how far we want to go before 1.0.
Yes such a Wiki would be very useful :)
>
>
>>Judging the quality of the FOP trunk code base is much harder. For
>>example, we still get reports of NPEs and AIOOBs. We don't know how it
>>will perform when asked to render 1000's of documents a day. We don't
>>know if there are any memory leaks. We don't know if its thread
>>safe....
Yes the fo:block inside fo:wrapper is a big one ATM. Although 0.20.5 has
no beta mark and it has far more NPEs and AIOOBs.
<snip/>
> Yes, it's a balancing act. But we've been too shy with our version
> numbers in the past. I don't like to see that continue for too long.
> We've lost a lot of supporters along the way. I want to get over that
> damn 1.0 barrier. Soon. And we have to do that with our limited
> resources.
I completely agree.
Chris
Re: When to release 1.0?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 18.06.2006 13:26:00 Manuel Mall wrote:
> On Sunday 18 June 2006 18:53, Jeremias Maerki wrote:
> > I just realized we should think about the right moment to release
> > 1.0. I guess the number of fixed bugs would suggest a new release
> > rather sooner than later. I originally thought about going for an
> > ApacheCon release but I didn't have enough time. Now, Vincent is
> > working on floats and the requirement for changing IPD between pages
> > gets more important (see fop-users and one of my clients would like
> > to see an increase in priority). However, both points may have a
> > serious impact on the layout engine especially since both feature
> > have a certain conflict potential for the page breaking approach.
> > Manuel and I have chatted over Skype about this and Manuel will also
> > look a little deeper into the issue. I suspect both items will
> > require substantial changes in the layout engine which are probably
> > better done after the next release (or on a separate branch). I think
> > it would be good to do the 1.0 release some time in July, if
> > possible.
> >
> > WDYT?
> >
>
> Calling a release 1.0 is IMO quite a significant step which shouldn't
> been taken lightly. What we are saying in doing so is: Here is
> something we believe is ready for production use.
Yes, but neither should we put off a 1.0 for much longer. Having a 0.x
version number is a big disadvantange. OTOH, when I released Barcode4J
1.0 it was almost too perfect. Almost no serious problems and also
almost no third-party patches. No community building. One-man show. :-(
In 2005 we saw an increase in interest to help with the development of
FOP. This year I get the impression that this wave is ebbing away again.
I wonder why. But I also wonder how we can improve that. A 1.0 release
would be a good signal. Does a 1.0 have to be perfect? M$ usually needs
at least two service packs to reach a usable level for their software.
Poor excuse, I know, but still, it somehow applies. And frankly, the
quality level we can automatically maintain with our test suite today is
quite remarkable. That said, I believe FOP is ready for production use
now.
> So from my perspective we need to answer two questions in the positive:
>
> A) Does this version of FOP deliver a sufficient degree of compliance to
> the XSL-FO spec to be considered ready for production use?
For which user? The degree of compliance the various user groups need is
quite different. For the business documents I've worked with so far in
my FO experience I wouldn't hesitate to use FOP Trunk in production.
Were I someone who needs to create book-style documents I'd probably
say: Hey, why should I use this crap if it doesn't even handle
page-number-citations correctly in a table of contents? What I want to
say is that you can't make a software usable to the same level for
everyone. There are users out there who still think XSL-FO is the right
tech to create large tabular reports with hundreds of pages. I wonder
why some managers still think they need these reports. (sorry, getting
carried away)
Judging FOP Trunk by the level of compliance of 0.20.5 is certainly one
way of answering this question but it is not necessarily the only way.
> B) Does it deliver those features with the required level of quality
> expected from an ASF product?
We've had over half a year of bugfixing and stabilization and we have a
very precious test suite which helps keeping the number of regressions
very low. Only the renderers are not really covered by automated tests
because that's quite difficult to do right with a good ROI. That, combined
with the feedback from the community, tells me we're good enough. IMHO,
of course.
> How can we answer those questions?
>
> For A) IMO it is easy. The old FOP version (0.20.5) is used in many
> production environments. If we meet or exceed compliance compared to
> 0.20.5 I would give A) a tick. However, ATM we are still behind 0.20.5
> in some areas although well ahead in many others.
Ok, so we need a Wiki page where we can track the progress for the view
on FOP Trunk. And we need to agree on how far we want to go before 1.0.
> Judging the quality of the FOP trunk code base is much harder. For
> example, we still get reports of NPEs and AIOOBs. We don't know how it
> will perform when asked to render 1000's of documents a day. We don't
> know if there are any memory leaks. We don't know if its thread
> safe....
But don't neglect to mention how many people are perfectly happy with
FOP 0.92beta and FOP Trunk... You're overly negative if you ask me. Note
that the negative side is often louder than the positive. But we did
have quite a bit of positive feedback.
Can we answer the questions above much better for 0.20.5? Maybe we just
know better where its limitatons lie. 0.20.5 has many bugs and it is
still used in production in many places.
> Of course one can argue that until we release a 1.0 users won't use FOP
> trunk in production environments and we won't find out about any of
> those possible deficiencies until they do.
>
> So, it is an interesting balancing act. At this point I am undecided
> (and my vote would be informal any way as only PMC members have binding
> votes).
Yes, it's a balancing act. But we've been too shy with our version
numbers in the past. I don't like to see that continue for too long.
We've lost a lot of supporters along the way. I want to get over that
damn 1.0 barrier. Soon. And we have to do that with our limited
resources.
Jeremias Maerki
Re: When to release 1.0?
Posted by Manuel Mall <mm...@arcus.com.au>.
On Sunday 18 June 2006 18:53, Jeremias Maerki wrote:
> I just realized we should think about the right moment to release
> 1.0. I guess the number of fixed bugs would suggest a new release
> rather sooner than later. I originally thought about going for an
> ApacheCon release but I didn't have enough time. Now, Vincent is
> working on floats and the requirement for changing IPD between pages
> gets more important (see fop-users and one of my clients would like
> to see an increase in priority). However, both points may have a
> serious impact on the layout engine especially since both feature
> have a certain conflict potential for the page breaking approach.
> Manuel and I have chatted over Skype about this and Manuel will also
> look a little deeper into the issue. I suspect both items will
> require substantial changes in the layout engine which are probably
> better done after the next release (or on a separate branch). I think
> it would be good to do the 1.0 release some time in July, if
> possible.
>
> WDYT?
>
Calling a release 1.0 is IMO quite a significant step which shouldn't
been taken lightly. What we are saying in doing so is: Here is
something we believe is ready for production use.
So from my perspective we need to answer two questions in the positive:
A) Does this version of FOP deliver a sufficient degree of compliance to
the XSL-FO spec to be considered ready for production use?
B) Does it deliver those features with the required level of quality
expected from an ASF product?
How can we answer those questions?
For A) IMO it is easy. The old FOP version (0.20.5) is used in many
production environments. If we meet or exceed compliance compared to
0.20.5 I would give A) a tick. However, ATM we are still behind 0.20.5
in some areas although well ahead in many others.
Judging the quality of the FOP trunk code base is much harder. For
example, we still get reports of NPEs and AIOOBs. We don't know how it
will perform when asked to render 1000's of documents a day. We don't
know if there are any memory leaks. We don't know if its thread
safe....
Of course one can argue that until we release a 1.0 users won't use FOP
trunk in production environments and we won't find out about any of
those possible deficiencies until they do.
So, it is an interesting balancing act. At this point I am undecided
(and my vote would be informal any way as only PMC members have binding
votes).
> Jeremias Maerki
Manuel
Re: When to release 1.0?
Posted by Jess Holle <je...@ptc.com>.
Jeremias Maerki wrote:
> Joerg,
>
> I'm glad you volunteer to do any changes. But there's also something
> else. We had a vote in March about merging back the "API Finalization"
> branch back into Trunk. You voted +1 back then knowing the the branch
> had the word "Finalization" in it. Furthermore, we've already
> communicated with 0.92beta that "the API is now considered stable" [1].
> So, if the committership feels we should take another round of API
> improvements, I won't block (your suggestions are all reasonable) but I
> won't take the lead here. Either you or someone else has to take the
> lead and push for it (consensus gathering, changes, documentation,
> communication...).
>
As one who took the time to write up some messy reflection code to allow
my simplistic use of FOP to work with both 0.20.5 and 0.92beta based on
the term "API finalization", I would like to see the API actually
finalize. For that matter, it would have been nice to keep 0.20.5
compatibility APIs around for very simple usages like mine (I was just
doing new Driver(), setOutputStream(), setRenderer(), and
getContentHandler() -- that's it, nothing fancy). Having to create
reflection code to span these 2 versions is a pain and having to keep
changing the reflection code as someone keeps changing the API is rather
annoying -- especially since missing an API change will result in a
runtime error later on down the line.
I'm not saying, "no, absolutely don't change the API". I am saying if
you really feel you must do it once more and never again -- and loudly
proclaim the mistake and *exactly* what you changed between 0.92beta and
the final API so I don't have to hunt around. [I can't just recompile,
of course, as my code is all using reflection as I have to support
0.20.5 until something 0.9x or later is actually officially marked as
stable -- and for a bit thereafter for other 0.20.5 usages to be altered
to be 0.9x API compliant.]
--
Jess Holle
Re: When to release 1.0?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jun 21, 2006, at 08:39, Jeremias Maerki wrote:
<snip />
Hi guys,
Sorry for being late. Just been reading this thread, and apart from
the other comments already made, I agree with the plan to release,
and I share most of the other committer's feelings wrt the version
number. Whilst 1.0 may be a bit premature, it is becoming more and
more of a necessity to draw more attention to FOP.
As for myself, I have only one serious issue on my list that needs
being looked at, in the area of multithread safety. There's still a
very suspicious static left in FOText.java, which may cause trouble --
or at least, highly erratic/unpredictable behaviour-- when multiple
documents are processed concurrently in the same JVM. As a positive
note: unwanted side-effects should only arise when two or more of
those documents are extensively using text-decoration and/or text-
transform.
I'll make it a priority to finish this ASAP, so this is out of the way.
As far as concerns the other 'showstoppers': I assume there will
still be at least one 1.0RC before actually releasing a definitive
version. Maybe we can use this to our advantage, as in: announce a
release candidate RC1 while explicitly mentioning that there are
still open issues and questions to be answered.
We could announce the first RC sooner rather than later, and release
the actual 1.0 in november (or beginning of 2007) as long as we have
RC2 to RC5 in between?
Important thing will be that the signal is given that we are
confident enough about this product to jump over that barrier, albeit
with a few reservations...
Just my 2 cents.
Later,
Andreas
Re: When to release 1.0?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> We had a vote in March about merging back the "API Finalization"
> branch back into Trunk. You voted +1 back then knowing the the branch
> had the word "Finalization" in it.
Some things just need time to sink in.
I don't want style issues block further progress. I brought this
topic up only because this seems to be the very last chance for
changes. If everybody is ok with as is, then just go forward.
J.Pietschmann
Re: When to release 1.0?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Joerg,
I'm glad you volunteer to do any changes. But there's also something
else. We had a vote in March about merging back the "API Finalization"
branch back into Trunk. You voted +1 back then knowing the the branch
had the word "Finalization" in it. Furthermore, we've already
communicated with 0.92beta that "the API is now considered stable" [1].
So, if the committership feels we should take another round of API
improvements, I won't block (your suggestions are all reasonable) but I
won't take the lead here. Either you or someone else has to take the
lead and push for it (consensus gathering, changes, documentation,
communication...).
I'm leaving tomorrow for Ireland and will be away for another week after
ApacheCon on "green holidays" (Swiss style), so I wouldn't have time
anyway. But I'll try to keep an eye on the lists as often as possible.
[1] http://xmlgraphics.apache.org/fop/0.92/upgrading.html
On 20.06.2006 23:24:15 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > Ok, if we want that 1.0 won't be out before September.
>
> Too bad. As already mentioned, changing IPD page masters worked
> reasonably well in 0.20.5 and I think people will expect this to
> work in a 1.0 release too.
>
> OTOH, if the frequency of questions on the lists are taken into
> account, support for collapsing table borders, even if only partial,
> has a much higher priority. I don't see any of the other mentioned
> features as a show stopper for 1.0.
>
> > That remark comes pretty late, but yeah, if anyone else think this
> > should be fixed, we should do it SOON.
>
> Well, someone should have looked at this before (I made some style
> related notes during the API discussion).
> The guide lines are
> - consistency with the Java RTL identifier guide lines, in particular
> the rule that common acronyms in identifiers are all upper case
> - internal consistency
> - avoiding redundancy
> We can restrict this to the essential user visible API, i.e.
> the packages o.a.fop.apps and o.a.fop.cli.
>
> My suggestions
> - Rename o.a.fop.apps to o.a.fop.api. This is a major change breaking
> everything, and should have been done in the same step when the
> Driver was replaced by the Fop class. I wont insist on this change.
> - If the "Fop" in FopFactory is the acronym for "FO processor", the
> class should be named FOPFactory instead. Same for Fop --> FOP
> (precedent is the java.net.URL class).
> - If it's the other way around FOPException should be renamed as
> FopException.
> - MimeConstants should be renamed as MIMEConstants.
> - FOURIResolver should probably be renamed as plain URIResolver (the FO
> prefix may be deemed redundant because of the package), or as
> FOPURIResolver. Two consecutive acronyms in an identifier are awkward
> in any case.
> - Same for FOUserAgent --> UserAgent or FOPUserAgent
> - The method applyHttpBasicAuthentication should be renamed
> applyHTTPBasicAuthentication.
> - Rename the CLI parameter "-param" to "-xsltparam" or something (too
> generic)
> We could keep and deprecate the unrenamed classes in order to ease the
> transition. If the API is really declared "stable", the beta tag can
> be dropped from the release number even for a pre 1.0 release.
>
> Should we hold a formal vote on the API style issue? Either way, I'd
> even volunteer to do the changes (it's easy enough :-).
>
> J.Pietschmann
Jeremias Maerki
Re: When to release 1.0?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Ok, if we want that 1.0 won't be out before September.
Too bad. As already mentioned, changing IPD page masters worked
reasonably well in 0.20.5 and I think people will expect this to
work in a 1.0 release too.
OTOH, if the frequency of questions on the lists are taken into
account, support for collapsing table borders, even if only partial,
has a much higher priority. I don't see any of the other mentioned
features as a show stopper for 1.0.
> That remark comes pretty late, but yeah, if anyone else think this
> should be fixed, we should do it SOON.
Well, someone should have looked at this before (I made some style
related notes during the API discussion).
The guide lines are
- consistency with the Java RTL identifier guide lines, in particular
the rule that common acronyms in identifiers are all upper case
- internal consistency
- avoiding redundancy
We can restrict this to the essential user visible API, i.e.
the packages o.a.fop.apps and o.a.fop.cli.
My suggestions
- Rename o.a.fop.apps to o.a.fop.api. This is a major change breaking
everything, and should have been done in the same step when the
Driver was replaced by the Fop class. I wont insist on this change.
- If the "Fop" in FopFactory is the acronym for "FO processor", the
class should be named FOPFactory instead. Same for Fop --> FOP
(precedent is the java.net.URL class).
- If it's the other way around FOPException should be renamed as
FopException.
- MimeConstants should be renamed as MIMEConstants.
- FOURIResolver should probably be renamed as plain URIResolver (the FO
prefix may be deemed redundant because of the package), or as
FOPURIResolver. Two consecutive acronyms in an identifier are awkward
in any case.
- Same for FOUserAgent --> UserAgent or FOPUserAgent
- The method applyHttpBasicAuthentication should be renamed
applyHTTPBasicAuthentication.
- Rename the CLI parameter "-param" to "-xsltparam" or something (too
generic)
We could keep and deprecate the unrenamed classes in order to ease the
transition. If the API is really declared "stable", the beta tag can
be dropped from the release number even for a pre 1.0 release.
Should we hold a formal vote on the API style issue? Either way, I'd
even volunteer to do the changes (it's easy enough :-).
J.Pietschmann
Re: When to release 1.0?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 18.06.2006 22:54:41 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > I just realized we should think about the right moment to release 1.0.
>
> I think 1.0 should implement page masters with different
> body width in the same page sequence.
Ok, if we want that 1.0 won't be out before September.
> I also have the vague feeling there are still slight API
> and CLI changes necessary for better consistency (e.g. class
> names like FOPException vs. FopFactory).
That remark comes pretty late, but yeah, if anyone else think this
should be fixed, we should do it SOON.
Jeremias Maerki
Re: When to release 1.0?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> I just realized we should think about the right moment to release 1.0.
I think 1.0 should implement page masters with different
body width in the same page sequence.
I also have the vague feeling there are still slight API
and CLI changes necessary for better consistency (e.g. class
names like FOPException vs. FopFactory).
J.Pietschmann