Convention for a distribution package

[Ahmed Moustafa]

Is there a convention to what to include (folders and files) in an open
source package?

 

[Harald Hein]

Is there a convention to what to include (folders and files) in an
open source package?

At least the source code

I would suggest you e.g. go to the fsf web site and have a look at some
GNU packages and their organisataion. I personally like tar files (for
java that would be zip/jar archives) with the following structure:

All stuff start under one directoy in the archive, containing the name
and the version of the software, and then some easy to identify text
files and subdirs. A simple package layout might look like:

<name>-<version>/README - ASCII file explaining the package and
providing contact details, installation
instructions etc.
INSTALL - If the build and installation procedure
is more complex and isn't in the README.
I don't like it too much. I prefer to
have everything in the README
COPYING - The license if you use the GPL or a
similar file like COPYRIGHT or LICENSE
containing your license.
ChangeLog - What has changed between versions
Makefile - Root file of the build system. If you
don't use makefiles then something
specific to your build system (ant).
If you want to be nice to your users,
DON'T use anything fancy which requires
any additional installation. DON'T use
non-standard or the latest features of
the build system. It should work with
the oldest version of the build tool
one can imagine.
src/ - source code
doc/ - documentation
examples/ - guess what
test/ - test programs

For Java you might consider to deliver an additional package that
contains a pre-compiled version (.class class files) of your software.
That package should blend-in well with the source distribution (can be
installed in the same directory, so should not overwrite each other's
files), also contain the license and a pointer to the source
distribution.

If your software relies on other libraries, non-standard build tools,
etc. (anything that requires additional downloads), consider offering a
complete package for download, too.


Harald

 

[Brian Palmer]

Harald Hein wrote:

Harald, thank you so much for your reply!!!

Should all these elements be held under cvs? Or only the source code?

Basically, any fundamental element that can change, should be entered
into cvs (or whatever revision-control system you're using). For
example, keeping the contents of
doc/
in your CVS repository is a good idea, if you've spent time creating a
manual. This is probably version-specific, so when you check out a
past version of your product, you want to get the manual that's
associated with it. When you make revisions to the product, you should
plan on updating the manual, and you'll want to track those changes,
too.

But if all doc/ is for is piping javadoc output, there's no point in
adding it to cvs, since you can always regenerate it from the source
code that you checked out.