Artifact 39df1905cf6f023756cbdff39af51d26ed6d4554:
- File developer-guide.mkd — part of check-in [da935c7872] at 2019-01-01 15:05:10 on branch trunk — Add developer guide which is used for making releases. (user: stephanie.gawroriski size: 3229)
# Developer Guide This is a guide for developers to follow for various parts of the repository. ## Releasing When a release is to be made, it is performed in another branch and becomes separate from `trunk`. This means that `trunk` is always in a state of perpetual development. Within these branches, there are bug fixes and releases. When a commit is ready for a release then it should just be tagged and built accordingly. It is best to avoid having releases and such in the `trunk` branch because it will complicate bug fixes and other things. So when a release is to be made: * Update the changelog with the planned release date if it is known at the time, otherwise it is not known. * Fork the branch and make a new branch from `trunk` for the release to be done, an example would be `release-0.2.x`. * In the new `release-0.2.x` branch, update the version numbers in the appropriate places so things are updated. * Tag the commit as `0.2.0` or an increasing release version (example: `0.2.1`) for each increasing release. * Do all the common release stuff. * While in `trunk`, do the following: * The development version can be bumped in which case the version will be incremented by two and will be odd (3, 5, 7, etc.). * Add the next version to the changelog, so that it may be updated when there is a new major change. ### Bug-fix and Otherwise Releases If a bug-fix or otherwise has to be done on a release version, since the release is in its own branch, the work can be done in that branch. Any fixes should have already been made in `trunk` if applicable, then it can be cherry picked into the release branch. Then once the fixes have been made and a new version is released the release version should be incremented (that is `0.2.0` to `0.2.1` to `0.2.2`). Then any of the release related stuff should be done. ### Common Release Stuff When a release is done, all of the binaries and according information must be updated. It is assumed that `SQUIRRELJME` is an environment variable to the root of the SquirrelJME source tree. Checkout the tag or commit which the release is to be done on. Then run the following command: * `$SQUIRRELJME/utils-dev/uploadrelease.sh $__release_version__` This will perform an auto-build of everything and then store the release in the `$__release_version__` directory, these binaries are important. Once the binaries and sources are built, they should be uploaded to the following locations: * Fossil (<https://multiphasicapps.net/>) * The `uploadrelease.sh` script takes care of putting the files in the repository. * You will need to edit the download page to add the new version, this will be done with `fossil unversion edit download.mkd`. * Synchronize the repository with the unversioned space. * GitHub * Go to releases. * Draft a new release. * Choose the release tag you just made. Note that there might be a delay before GitHub is updated, so be patient or force it to update manually. * Title the release. * SourceForge * Create a new directory for the release number. * Upload all of the files into that directory. * Appropriately set the operating systems for the binaries.