> -----Original Message-----
> From: Arved Sandstrom [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 15 August, 2001 10:24
> Subject: RE: Release Process Improvements, Versioning etc
> At 10:42 AM 8/14/01 +0200, Michel Lehon wrote:
> >> From: Weiqi Gao [mailto:[EMAIL PROTECTED]]
> >> On 13 Aug 2001 22:08:50 +0000, Arved Sandstrom wrote:
> >> > ...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.
> I don't want to call these things "betas" or "alphas", since they aren't.
> The purpose isn't really different, though, so I'm not religious over it.
> Open-source has fuzzied the meanings up anyway.
> The pre-release period is meant to be quite short. Weiqi points
> out that we
> should RERO (Release Early, Release Often); he's quite right.
> We've tried to
> release at least once a month, and maybe even every 2 weeks, without much
> success to date. But if we were releasing once a month I wouldn't want to
> see more than 3 or 4 days allocated to a pre-release code freeze, myself.

I think it would be nice to have something like
code freeze + release, lets call it CF (like code freeze)
have one week to test it, integrate with other projects...
do a release without the CF suffix ?

> >> 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.
> Well, we have a whole whack of JBoss documentation to play
> with...that's a
> project begging for a volunteer. We could also independently showcase the
> use of DocBook, for example.
> Finally, all of our own docs should be amenable to FOP processing.

Indeed, it of this sounds great.

> >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.
> I simply do not understand this point. How is a ZIP file easier?

OK, let's call this .2 euro psychology, I know many Windows users that
are put off by .tar.gz files, they think these files are for Unix dist.
So having a .zip as a file format for the distibution (at least the bin)
helps to get those users try and use FOP.
And last every other project as both distibutions, .zip and .tar.gz

Michel Lehon
Partner, Outwares sprl.
SAS Data Warehousing and Web Enablement.

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to