
1. REQUIREMENTS
---------------

JDK 1.3
  Sun Microsystems, Inc.

Ant 1.4 and 1.3
  Build Tool
  by The Jakarta Project
     Apache Software Foundation
  http://jakarta.apache.org/ant/

SableCC 2.16.2 (sablecc.jar)
  Parser Generator
  by Etienne M. Gagnon
  http://www.sablecc.org/
  maintained in CVS

Xerces 1.4.3 (xerces.jar)
  XML Parser
  by The Apache XML Project
  http://xml.apache.org/xerces-j/
  maintained in CVS

JUnit 3.7 (junit.jar)
  Test Framework
  by Kent Beck and Erich Gamma
  http://junit.org/
  maintained in CVS

NOTES:
* JDK 1.2 will fail with field java.util.Collections.EMPTY_MAP missing.


2. CHECK IN POLICY
------------------

All the rules below are valid regardless whether a conflict is
caused by a bug in one of the tools. If a conflict really
causes pain, I may decide to upgrade the version of the tool.

No one gets hung, when violating the rules (I even did this
myself). You'll get a friendly email.

2.1 Compile
-----------

"ant clean compile" must succeed with the following compilers:

* javac of the SUN JDK java version "1.3" and later
* jikes Version 1.06 (17 Sep 99) BUT NOT LATER

For how to enable jikes, and which versions to use, see file
jikes.properties in this directory.


NOTE:
It may be the case that the javac compiler produces out of memory exceptions.
When using the javac compiler directly,this problem can be solved by using
the -J-mx<number> switch.
When using Ant to compile the sources, one must increase the available memory
to the compiler by editing the last line of the file ant (or ant.bat respectivly)
in the bin folder of Ant's installation path in the following way:

$JAVACMD -Xms128m -Xmx128m -classpath "$LOCALCLASSPATH" -Dant.home="${ANT_HOME}" $ANT_OPTS org.apache.tools.ant.Main "$@"

The example shows how to increase the available memory to 128 mb by the first two
parameters.

2.2 Jars
--------

"ant clean jar" must succeed.

Besides compiling jar-files are created and checked for static
closure. Note, that "ant jar" does not compile test classes as
"ant compile" does.

2.3 Javadoc
-----------

"ant docs" must succeed and must not produce any warnings.

2.4 Test Suites
---------------

"ant test" must succeed.

2.5 Tabs
--------
You are free to use tabs for identing or not. If you do, a single
tab is exactly ONE level of identation.
You may mix tabs and spaces within a file, but then tab width is 2,
in words "two".

2.6 CHANGELOG
-------------
Every commit resulting in a changedbehaviour (probably anything
besides beautifying code) gets a record there. Please don't forget
to document your changes. A policy for CHANGELOG entries is at the
end of that file.


3. RELEASE POLICY
-----------------

3.1. Release Numbers
--------------------
Each release gets a unique number in the form of major.minor.revision.

* Major numbers are reserved for compatibility breaking restructurings
  ofthe whole project.
* Minor numbers are for changes breaking source or binarycompatibility,
  but require small efforts to adapt existing applicationsusing the
  OCL Toolkit.
* Revision upgrades guarantuee source and binary compatibility.

3.2. CVS Tags
-------------
Each release is tagged with "RELEASE_<release number>". Where dots ('.')
in <release number> are replaced by underscores ('_'). This is necessary
because cvs tags may not contain dots.

The following isstrictly required: after a

 cvs update -r RELEASE_<release number>
 ant clean dist -Ddist.version=<release number>

one gets exactly the released files offered for download on the server,
except of the file time stamps.

3.3 RELEASE PROCEDURE (as a result of the above)
------------------------------------------------
1)  Get the desired version (probably the most current) from CVS

2a) ant clean all,
    proceed only if everything is ok, according to CHECK-INpolicy in README

2b) Do any additional tests, which cannot be doneautomatically. Yet to be
    specified, at least the interactive applets shouldbe started and a minimal
    clickthrough should be performed.

3)  Choose arelease number according to 3.1.
    This number is represesented by <new release number> below.

4a) Edit CHANGELOG: Replace the title of the first section
      "Changes fromx.y.z to current CVS"
    to
      "Changes from x.y.z to <new release number>"

4b)cvs commit -m "closed section for <new release number>" CHANGELOG

5)  cvs tagRELEASE_<new release number>, where dots ('.')
    in <release number> are replaced by underscores ('_').

6)  ant dist -Ddist.version=<new release number>
    After that, you will find the following in directory dist

    * dresden-ocl-<new release number>.tar.gz
      containing everything needed for usingthe toolkit: jars, docs, etc.
    * dresden-ocl-<new release number>-src.tar.gz
     containing the image of a freshly checked out cvs of this version.
      Thismeans: all files maintained in CVS.

7a) Edit CHANGELOG: Add a new section on top:
      "Changes from <new release number> tocurrent CVS"

7b) cvs commit -m "opened section for post-<new releasenumber>" CHANGELOG

8)  Upload the files created by 6) to sourceforge into the
   "released files section".

9)  Make announcement in dresden-ocl-discussion.
   Subject is "released version <new release number>". Put the corresponding
   section of CHANGELOG into that mail.

10) (Optional) Propose anannouncement for dresden-ocl-announce on
    dresden-ocl-discussion. Such anannouncement demands careful evaluation.
    There should be at least three month between messageson dresden-ocl-announce.



Ralf.
