cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Information about the 2.1M1
Date Tue, 29 Apr 2003 14:44:12 GMT
"Carsten Ziegeler" <> wrote:

> Pier Fumagalli wrote:
>> I'll write up on this once I'm finished fixing those distro bugs I
>> introduced...
> Great! Thanks Pier!

Ok, I've put up the distros for M1 on the main download area. And fixed the
bugs I introduced in the mirrored download system (I'm an idiot), rsynced
nagoya (just to make sure that things are working properly), and cleaned up
few bits and bobs...

Note, those are following the Apache Mirroring Guidelines (don't ask me
where those are, somewhere, they were discussed on infrastructure@), or how
I remember them with my _very_ bad memory (anyhow, they _do_ work! :-)


A) Naming Conventions:

The name of each downloadable archive should be named after the following
regular expression:


- PROJECT is the name of the top-level project,
- SUBPROJECT is the name of the eventual subproject (optional)
- VERSION is a version string (without - dashes)
- VARIANT identifies the "type of distribution" (ex. win32, jdk12,
  linux, jdk14...) (optional)

So, in Cocoon's case, all our archives shall be called something like:



and so on...

If one day we ever released some subproject code (for example Lenya), the
name should be along the lines of

You get the point.

B) Directories:

The only (ONLY) place where distributions shall reside is inside the
/www/ on

This directory contains three subdirectories:

- BINARIES: this is where the binary distribution tar/zipballs are located.
- SOURCES: this is where the source distribution tar/zipballs are located.
- OLD: all old and deprecated distributions.

In the future, when other subprojects of Cocoon will start putting out their
own releases, new directories will be created under the top level directory,
with the same structure. For example the final directory will look something

|  |
|  +- cocoon-2.0.3-bin.tar.gz
|  |
|  \- cocoon-2.0.4-bin.tar.gz
|  |
|  +- cocoon-2.0.3-src.tar.gz
|  |
|  +- cocoon-2.0.4-src.tar.gz
|  |
|  +- cocoon-2.1m1-src.tar.gz
|  |
|  \- cocoon-2.1m2-src.tar.gz
+- OLD/
|  | 
|  +- cocoon-1.8.1.tar.gz
|  |
|  \- cocoon-1.8.2.tar.gz
+- cocoon-latest-bin.tar.gz -> BINARIES/cocoon-2.0.4-bin.tar.gz
+- cocoon-latest-src.tar.gz -> SOURCES/cocoon-2.0.4-src.tar.gz
+- lenya/
|  |
|  |  |
|  |  \- cocoon-lenya-1.0-bin.tar.gz
|  |
|  +- SOURCES/
|  |  |
|  |  \- cocoon-lenya-1.0-src.tar.gz
|  |
|  +- cocoon-lenya-latest-bin.tar.gz -> BINARIES/cocoon-lenya-1.0-bin.tar.gz
|  |
|  \- cocoon-lenya-latest-src.tar.gz -> SOURCES/cocoon-lenya-1.0-src.tar.gz
\- license.txt

C) Publishing and linking:

Once the distribution ball is rolled following the naming convention and
copied in the appropriate directory as outlined above, make sure that the
following links are present (and only those links) in the root directory for
the project/subproject:

- A link to the latest released stable version for each tar/zipball:
  for example, if the latest release is 2.0.4, and this release includes
  3 different balls, 2 for binaries and 1 for sources, the following
  links must be done:
  # cd /www/
  # ln -s BINARIES/cocoon-2.0.4-vm14-bin.tar.gz cocoon-2.0.4-vm14-bin.tar.gz
  # ln -s BINARIES/
  # ln -s BINARIES/cocoon-2.0.4-bin.tar.gz cocoon-2.0.4-bin.tar.gz
  # ln -s BINARIES/
  # ln -s SOURCES/cocoon-2.0.4-src.tar.gz cocoon-2.0.4-src.tar.gz
  # ln -s SOURCES/

- A link to the latest milestone version for each tar/zipball (if present):
  for example, if 2.1m1 publishes only one ball, the source one:
  # cd /www/
  # ln -s SOURCES/cocoon-2.1-src.tar.gz cocoon-2.1-src.tar.gz
  # ln -s SOURCES/

- A link to the LATEST STABLE DOWNLOADABLE with the "version" string
  replaced by the "latest" keyword. If the above example of 2.0.4 is still
  # cd /www/
  # ln -s BINARIES/ccoon-2.0.4-vm14-bin.tar.gz cocoon-latest-vm14-bin.tar.gz
  # ln -s BINARIES/
  # ln -s BINARIES/cocoon-2.0.4-bin.tar.gz cocoon-latest-bin.tar.gz
  # ln -s BINARIES/
  # ln -s SOURCES/cocoon-2.0.4-src.tar.gz cocoon-latest-src.tar.gz
  # ln -s SOURCES/

Make sure to change the "latest version" strings and URLs in the README.html
and HEADER.html files in the /www/ directory and
the mirror.html file in the /www/ directory (once the
site gets moved to it will be in the
/www/ directory)

Note that for release final downloads you shouldn't edit the mirrors.html
file, as the release should always be linked to cocoon-latest-.....

D) Mirroring and announcing:

Once the release is published wait at least 24 hours before announcing it to
the mailing lists, so that mirror sites will have the opportunity to pick
the changes up and you won't get bugged by people unable to download the

Remember that the locations to mention in any announcements when downloads
are involved is

So that people will actually _use_ the mirrors and not peg the Foundation's
bandwidth (which is quite expensive).

Have fun...



View raw message