> From: Weiqi Gao [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 14 August, 2001 05:27
> To: [EMAIL PROTECTED]
> Subject: Re: Release Process Improvements, Versioning etc
> 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.)
How about beta releases ? like they do for Tomcat, Cocoon, ...
The beta cycle would be nice for bug fixes, user feedback, and integration
with other projects.
For examples I think Cocoon 2 will be hit by the same problem as I had
(removed methods, NullPointerException when using the ContentHandler),
and for which I submitted a patch (Ok, it was not a diff)
> > 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.
That would really be great.
> > 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.
That could be avoided using a beta cycle... however that should not
prevent a 0.20.1 or 0.20.2 to happen.
> > 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.
Again a beta cycle would be nice.
and last, how about a zip file for windows users (I know winzip can handle
.tar.gz), I would be easier and would not put off normal windows users.
Partner, Outwares sprl.
SAS Data Warehousing and Web Enablement.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]