Please follow these steps to produce a new release of xml-dtd.
-
The Git version control system is required to obtain the sources. Any recent version should suffice.
-
Java 11 or later. You can install it from your favourite package manager or by downloading from Adoptium.
-
The
generate_directory_index_caddystyle.py
script and a recent version of Python (required to run it). The script is necessary to create the index files in the bare-bones Maven repository currently used by xml-dtd.
- If your local copy of the xml-dtd Git repository exactly matches the current
master
HEAD, use that copy to execute thegradlew
commands shown later, otherwise create a new clone of thegit@github.com:css4j/xml-dtd.git
repository withgit clone
and use it.
For reference, let your copy of the xml-dtd release code be at
/path/to/xml-dtd
.
- Use
changes.sh <new-version>
to create aCHANGES.txt
file with the changes from the latest tag. For example if you are releasing4.3.1
:
cd /path/to/xml-dtd
./changes.sh 4.3.1
Edit the resulting CHANGES.txt
as convenient, to use it as the basis for the
detailed list of changes when you fill the RELEASE_NOTES.md
and the new
release in Github.
Complete the Release Notes and update the version in the Gradle example of
README.md
, also check whether the dependencies mentioned there are correct.
Commit the changes.
-
Bump the
version
in thebuild.gradle
file or remove the-SNAPSHOT
suffix as necessary. Commit and push all the changes to the Git repository. -
If there is an issue tracking the release, close it.
-
To check that everything is fine, build the code:
cd /path/to/xml-dtd
./gradlew build
-
Clone the
git@github.com:css4j/css4j.github.io.git
repository (which contains a bare-bones Maven repository) and let/path/to/css4j.github.io
be its location. -
From your copy of the xml-dtd release code, write the new artifacts into the local copy of the bare-bones Maven repository with:
cd /path/to/xml-dtd
./gradlew publish -PmavenReleaseRepoUrl="file:///path/to/css4j.github.io/maven"
- Produce the necessary directory indexes in the local copy of the bare-bones
Maven repository using
generate_directory_index_caddystyle.py
:
cd /path/to/css4j.github.io/maven/io/sf/carte
generate_directory_index_caddystyle.py -r xml-dtd
If the changes to the css4j.github.io
repository look correct, commit them but
do not push yet.
- Clone the css4j-dist repository and
execute
./gradlew mergedJavadoc
. Move the javadocs frombuild/docs/javadoc
to/path/to/css4j.github.io/api/latest
:
rm -fr /path/to/css4j.github.io/api/latest
mkdir /path/to/css4j.github.io/api/latest
mv /path/to/css4j-dist/build/docs/javadoc/* /path/to/css4j.github.io/api/latest
If the changes to the css4j.github.io
repo look correct, commit them with a
description like "Latest modular Javadocs after xml-dtd 4.3.1" and push.
Check whether the "Examples" CI
triggered by that commit to the css4j.github.io
repository completed
successfully. A failure could mean that the jar file is not usable with Java 8,
for example.
- Create a
v<version>
tag in the xml-dtd Git repository. For example:
cd /path/to/xml-dtd
git tag -s v4.3.1 -m "Release 4.3.1"
git push origin v4.3.1
or git tag -a
instead of -s
if you do not plan to sign the tag. But it is
generally a good idea to sign a release tag.
Alternatively, you could create the new tag when drafting the Github release (next step).
- Draft a new Github release at https://github.com/css4j/xml-dtd/releases
Use the contents of the RELEASE_NOTES.md
file to summarize the most important
changes in the release description.
Add to the Github release the jar files from this release.
-
Verify that the new Github packages were created successfully by the Gradle Package task.
-
In your local copy of the css4j-dist repository, update the xml-dtd version number in the maven/install-css4j.sh script. Commit the change, push and look for the completion of that project's CI.
-
If there is a Github milestone about this release, close it.