On 16/03/2010, Mladen Turk <mt...@apache.org> wrote: > On 03/16/2010 05:22 PM, sebb wrote: > > > > > The KEYS file is a bit old, but I assume it won't actually be used. > > > > Also, the source/ directory still has the 1.0.2 version in it, which > > confused me a bit. > > > > > > This has nothing to do with a release. > It's a folder README. fixed anyhow > > > > > The source/ dir also has a set of 1.0.3 binaries, however these are > > not the same as the identically named files in > > http://people.apache.org/~mturk/daemon/binaries/1.0.3/ > > > > > > Again wrong upload. fixed. > > > > > Is the code going to be released to Maven? If so, where are the artefacts? > > > > > > Nope. > > > > It would be nice if the zip archives used CRLF line endings > > > > > > -1. .zip is usable on platforms having broken tar like Solaris. > The files in windows/directory have CRLF
Seems to me that this is penalising Windows users for bugs on other OSes. Having the wrong EOLs on Windows makes it difficult to read the text files, because they tend to show up as a single long line. However, having an additional CR at EOL in Unix-like systems just makes the file look a bit messy in an editor, and is generally perfectly usable. Obviously, files that are intended only for use on Unix should still have EOL=LF. Should be quite easy in this case, as the source files are in different parts of the directory tree. > > > > > It's difficult to reconcile the archives with the SVN tag, as the > > directory structure is rather different. Is it necessary to use a > > different structure? In particular, SVN uses the directory name "nt" > > whereas the archives use "windows", which is very confusing. > > > > > > This is intentional. In future the nt will be renamed to > windows in SVN as well. > > > > Also, there's no details of how to build the native code in the archive > itself. > > > > Has nothing to do with a release process. > Someone will have to write that. > > > > Regards > -- > ^TM > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
