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
