Preparing the release
In order to get as much feedback as possible before a release, it’s preferable to announce it on GitHub by creating a dedicated ticket (see examples). This should be done at least one week in advance.
It’s also recommended to make the announcement on firstname.lastname@example.org.
Check the dev status
Before releasing a new version of FreshRSS, you must ensure that the code is stable and free of major bugs. Ideally, our tests should be automated and executed before any publication.
You must also make sure that the CHANGELOG file is up to date with the updates of the version to be released.
$ git checkout edge $ git pull $ vim constants.php # Update version number x.y.y.z of FRESHRSS_VERSION $ git commit -a Version x.y.z $ git tag -a x.y.z Version x.y.z $ git push && git push --tags
It’s important to update update.freshrss.org since this is the default service for automatic FreshRSS updates.
The repository managing the code is located on GitHub: FreshRSS/update.freshrss.org.
Writing the update script
The scripts are located in the
./scripts/ directory and must take the form
update_to_x.y.z.z.php. This directory also contains
update_to_dev.php intended for updates of the
edge branch (this script must not include code specific to a particular version!) and
update_util.php, which contains a list of functions useful for all scripts.
In order to write a new script, it’s better to copy/paste the last version or to start from
update_to_dev.php. The first thing to do is to define the URL from which the FreshRSS package will be downloaded (
PACKAGE_URL). The URL is in the form of
There are then 5 functions that have to be executed:
apply_update()takes care of saving the directory containing the data, checking its structure, downloading the FreshRSS package, deploying it and cleaning it all up. This function is pre-filled but adjustments can be made if necessary (e.g., reorganization of the
./datastructure). It returns
trueif no problem has occurred or a string indicating a problem;
trueif the user must intervene during the update or
ask_info_update()displays a form to the user if
save_info_update()is responsible for saving the information filled out by the user (from the
do_post_update()is executed at the end of the update and takes into account the code of the new version (e.g., if the new version changes the
Minz_Configurationobject, you will benefit from these improvements).
Updating the versions file
Once the script has been written and versioned, it’s necessary to update the `./versions.php’ file which contains a mapping table indicating which versions are updated to which other versions.
Here’s an example of a
<?php return array( // STABLE '0.8.0' => '1.0.0', '0.8.1' => '1.0.0', '1.0.0' => '1.0.1', // doesn’t exist (yet) // DEV '1.1.2-dev' => 'dev', '1.1.3-dev' => 'dev', '1.1.4-dev' => 'dev', );
And here’s how this table works:
- on the left you can find the N version, on the right the N+1 version;
x.y.z.z-devversions are all updated to
- stable versions are updated to stable versions;
- it’s possible to skip several versions at once, provided that the update scripts support it;
- it’s advisable to indicate the correspondence of the current version to its potential future version by specifying that this version does not yet exist. As long as the corresponding script does not exist, nothing will happen.
It’svery strongly recommended to keep this file organized according to version numbers by separating stable and dev versions.
Before updating update.freshrss.org, it’s better to test with dev.update.freshrss.org, which corresponds to pre-production. So update dev.update.freshrss.org and change the
FRESHRSS_UPDATE_WEBSITE URL of your FreshRSS instance. Start the update and check that it’s running correctly.
When you’re satisfied, update update.freshrss.org with the new script, test it again, and then move on.
Updating the FreshRSS services
Two services need to be updated immediately after the update.
- demo.freshrss.org (public login:
Publicly announce the release
When everything’s working, it’s time to announce the release to the world!
- on GitHub by creatinga new release
- on the freshrss.org blog, at least for stable versions (write the article onFreshRSS/freshrss.org)
- on Twitter (@FreshRSS account)
- and on email@example.com
Starting the next development version
$ git checkout edge $ vim constants.php # Update the FRESHRSS_VERSION $ vim CHANGELOG.md # Prepare the changelog for the next version $ git add CHANGELOG.md && git commit && git push
Also remember to update update.freshrss.org so that it takes the current development version into account.