On 13 Aug 2001 22:08:50 +0000, Arved Sandstrom wrote:
>
> I invite everyone to submit ideas as to how we can improve the
> release process: versioning, builds and testing. It seems like
> almost everytime a 0.X.0 release comes out, there is almost
> instantaneously a showstopper bug that necessitates a 0.X.1
> release, as happened this time.
If making a release reveals bugs, then there should be more releases.
"Release early, release often" is one of the tenets of Open Source.
> I don't want to dictate how things would work - we have a lot of
> good developers here who do configuration management, source
> control and testing in real life just as I do - but here are a
> few obvious ideas.
>
> 1) Believe it or not I can actually guarantee to do builds on a
> given date, now that I have a system for doing the CHANGES file
> rather rapidly. So once we have decided on a given date for a
> release, I suggest that we mandate a code freeze starting N days
> before the release. At the start of the freeze I build a pre-release
> distro, and it will be labelled as a pre-release (PR suffix maybe?)
> During those N days (2 days, 3 days?) everyone will have an
> opportunity to test the release, and find those bad bugs that
> somehow never showed up before.
That sounds like a very good idea. And I have seen other Apache
projects doing it. (Except that they are not calling it "PR". This is
another instance where Apache management should probably dictate all sub
projects to use a uniform name for the pre-releases.)
> 2) More comprehensive build tests. I am not so much concerned with
> how the PDF looks as just making sure we get no exceptions. Petr
> Andrs' font embedding examples, if used as build tests, would have
> caught a bad bug, for example. This testing is complementary to the
> testing Keiron Liddle has laid the groundwork for, which is oriented
> towards conformance testing.
I have not used the testing framework. I tried "./build.sh test" once
and it threw me some error message. It would be benefitial if the
testing frame work can be made to work in a way similar to the "make;
make check" sequence for GNU projects. That way more people would run
the test.
Make it a rule that "absolutely nothing will be committed without
clearing all the tests".
If feasible, solicit donations to the test case .fo files directory from
other applications, authors of XML books, the W3C recommendation
authors, and FOP users in general. The idea is to build a formidable
set of real world examples of .fo files, and .xml/.xslt files so as to
1) test FOP, and 2) show case FOP's capabilities. Wouldn't it be nice
if after building and testing FOP from a source download, the user gets
a subset of the W3C XSL 1.0 Recommendation (or a section of the DocBook
Definitive Guide, or Chapter 17 of the XML Bible) in PDF format ready to
be viewed, searched, and printed.
> 3) Versioning and build numbers: I hate putting up FOP-0.20.0, and
> 24 hours later putting up FOP-0.20.1, just for a bug fix. Granted,
> it was an important defect, and needed to be addressed right away,
> but I don't think it rates that kind of revision increment. I don't
> have any good suggestions (I know how I do things at work, but that's
> different). Any thoughts?
0.20.1 is fine. I don't have any issues with it. If another bug was
found and fixed tomorrow, I would be glad to use a 0.20.2. As it is
right now, I don't think that we are making a full use of the third
number anyway.
> I am sure there is other stuff also. My goal here is to develop a
> formal process document that describes exactly what I do, so that
> anyone with commit privileges can easily duplicate the complete
> release process.
A pre-release communication with other Open Source projects, like
Cocoon2, about API changes and other changes that may potentially impact
them is also critical.
--
Weiqi Gao
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
