httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@organic.com>
Subject 1.3a1
Date Mon, 21 Jul 1997 22:05:26 GMT
I think we're close to a 1.3a1 release. I've written some Windows docs,
and Ben's latest changes seem to make everything work, at least
minimally. There are just a few things left to fix. I think tomorrow
might be a good day for an alpha (Ben's likely sleeping right now, and I
want to give him a chance to complain about whatever it is I end up
screwing up this afternoon).

One thing we need to decide is how we want to handle line breaks:

Basically, Unix uses a single line feed to mark the end of a line, wheras
DOS/Windows uses a carriage return, and a line feed. This means that
unless the program is designed to handle alternate line breaks, text
files with one type of line break will not work with programs expecting
the other. But you all knew that already.

CVS for Windows is smart enough to handle this for you if you're using
CVS: For non-binary (-kb) files, it translates Unix line breaks to DOS,
and back again, when you check out and commit. So for development,
everything is good.

The problem is releases. When the distribution is packed up
(http://dev.apache.org/how-to-release.html), each file needs to have one
type of line break or another. So we need to decide how to handle
this. Here are three options:

1. Leave all line breaks as Unix. Require Windows users to somehow
   convert the neccessary files to the correct format, but leave it to
   them to figure out how.

2. MSVC++ can handle source files with Unix line breaks, but not
   makefiles/project files. So we could cvs admin -kb the .mak and .dsp
   files (and any other Windows-only files), give them Windows line
   breaks, and commit them that way. Then the Unix-made distributions
   would work, for the most part. There are a few problems with this,
   however:

   a) The non-Windows only files would not have Windows line
   breaks. README, for example. Or the source files. This could be an
   issue, depending on what editor is in use.

   b) If a Unix user edits one of the Windows files, but forgets to use
   Windows line breaks, and commits that, the file will end up with Unix
   line breaks, even if checked out with Windows CVS.

3. We can create seperate versions of the source distribution: We can
   make an apache_1.3*.tar.gz and apache_1.3*.tar.Z (as we do now) with a
   cvs export on Unix, and an apache_1.3*.zip with a cvs export on
   Windows. They would be identical, except for the format of their
   compression and the line breaks.

I think #3 is quite possibly the best solution, since it leaves the least
bit to confusion, both by developers and users. It also provides a
zipfile, which is a good idea at any rate, since Windows users may not
have access to gzip/tar. The only issue is that it would require the
release builder to have access to both Unix and Windows, or to have
access to someone who has access to both Unix and Windows (i.e. "I'll
build the release, but I need someone else to build the Windows
version.") This will be neccessary anyway, though, since we plan to
release special Windows binary versions alongside the source version, at
least from 1.3a2/1.3b1.

Thoughts?

-- Alexei Kosut <akosut@organic.com>


Mime
View raw message