Target audience

This part of the documentation is not meant for end users of Coppermine, but only for developers. There is absolutely no support for this section, it comes as-is. If you're not a member of the Coppermine dev team, then the contents of this page are not meant for you.

Git repository

In the first place you need to perform core actions on the Git repository level of Coppermine. For this purpose, you need to have write access to the Git repository, which is something you can not make up. A dev team member with project admin status needs to have granted you write access to the Git repository that is hosted at github.com. You need to have some experience in using your Git client before trying to accomplish the actions described here.

Steps

These steps need to be taken to package a new release.

• Pull

  As with all Git operations, you need to perform a pull to make sure that your working copy of the Git repository is up-to-date.

• Edit the version number

  To edit the version number of the Coppermine release, you will need to edit several files:
  • The actual version number is being stored in the file include/init.inc.php, so you will need to edit that file with a plain text editor and find , where X corresponds to the current minor version count that needs to be counted up.
  • The version number output of all pages of the documentation is being replaced using the JavaScript file behind each localization folder; that's why you need to loop through all language folders within the docs-folder, edit script.js, find the definition for the function cpgDocHeader and inside that definition change the localization line that corresponds to , where X stands for the minor version number.

• Replace version number in all files

  You need to loop through all text files (file extensions .php, .css, .js, .txt, .sql, .htm) and replace the version number in the header with the version number of the new release.
  
  You will have to find and replace with
  To accomplish this, you will need a tool that can batch-replace in files:

  • Linux

    On most posix-compliant operating systems (like Unix, Linux, BSD etc.) you should have all needed tools at hand already. Basically you loop through all files with a given extension, search for the string inside it and replace it. The command that can be run in a console could look like this: find /path/on/filesystem/level/to/your/working/copy/ -maxdepth 4 -name "*.php" -o -name "*.css" -o -name "*.js" -o -name "*.txt" -o -name "*.sql" -o -name "*.htm" | xargs sed -i 's/Coppermine version: 1.6.X/Coppermine version: 1.6.Y/g' If you want to turn this into a shell script, don't forget the shebang at the start of the file (usually something like #!/bin/sh).

  • Windows

    On Windows-driven computers you will need an editor that is capable to replace in multiple files or a tool that is dedicated to the replacement of text in files like the freeware apps Replace in files by Emurasoft or the app MB-Search&Replace by Markus Bader. Both apps are available in English as well as in German and both don't require an installation (the executable runs out of the box, even from a USB stick or similar).
  After having looped through all files, check in your Git client if you actually have changed all non-binary files inside the package - all files should be marked as "changed" in your Git client. Those that are not marked as changed require manual editing - maybe the version number had been forgotten to be changed in the previous release or when the file was added to the Git repository in the first place.
  Don't push your changes yet though; there are some more edits that need to be performed.

• Remove Byte Order Marks

  As Coppermine is a community effort and there are many developers who have write access to the Git repository it might happen that a Byte Order Mark (BOM) has crept into non-binary files. This happens without the developer being aware of it and shouldn't cause a lot of fuzz among the dev team, yet it can cause serious issues after the release, with the byte order mark shining through on some or all pages and especially with authentification issues, as the pre-mature start of the output (even if it's just the accidental output of the BOM) will interact with the browser's ability to receive the header and subsequently the cookie.
  That's the reason why it's a good idea to scan the non-binary files (file extensions .php, .css, .js, .txt, .sql, .htm) once more for the existance of a BOM and get rid of it if present. On Windows-driven computers, the BOM usually manifests with "funny" charcters - usually , so you should loop through all text-only files for that string and get rid of that string by replacing it with "" (nothing), using exactly the same tool used for the version number replacement above.

• Prepare an announcement thread

  Prepare an announcement thread in advance (before you actually release) inside the dev-only sub-board of the Coppermine forum. This thread can be empty - you can fill it later, or have another dev team member fill it. You need to create it in advance in order to be able to refer to the thread from within the documentation that will ship with the release.

• Edit the upgrade section of the docs

  Edit the upgrade section of the docs and (if you can) the other corresponding sections of the localizations of the docs. Find the table inside the section "Reasons for package releases" there and add a table row at the top with the needed information. Take a look at the other table rows that correspond to previous release to get an idea what should go into that section. Refer to the changelog file in the root folder to figure out about the changes that went into the release that you're about to package. Don't forget to refer to the announcement thread that you have created in the previous step to make sure you can inform users about last minute changes accordingly.

• Edit the changelog

  Add at least one line to the changelog that explains the version number change that you're about to push. Add a line as well that mentions the release date.

• Update the versioncheck data

  Edit the file include/cpg16x.files.xml inside your working copy of the Git repository with a plain text editor. Make sure that the XML file is complete. Loop through the changelog to check if all files (language files etc.) that have been added to the Git repository since the previous release have been added to include/cpg16x.files.xml file as well. If all developers have done as suggested, there should be nothing left to do for you in this aspect. Save your changes (if any).

• Push your changes

  Of course you need to push all your changes to the Git repository, using your Git client.

• Merge branches

  TODO: Add section how to update "master" with latest content of "develop"

• Create a release at GitHub.com

  Create a new release on GitHub.com.
  TODO: add simple explanation

• Clone master to fresh local directory

  By now it's time to create the actual package, so you may be tempted to just zip your local working copy of the Git repository, but that would be a very bad idea, as both your individual config file as well as all your changes (e.g. test uploads etc.) would be residing in that copy. Additionally, a lot of garbage would reside in that copy, as Git creates a lot of hidden files inside your local working copy.
  That's why you need to clone the "master" branch into a new, empty folder on your client and use that from now on. This will make sure that only the files that are meant to go into the package will actually go into your package.

• Create the archive

  Create an archive according to the naming conventions, using your favorite archiver (on Windows, 7-Zip is recommended). The naming convention for package releases is pretty straightforward: it's just the abbreviation cpg followed by the exact version number. Subsequently, your archive should be named cpg1.6.X.zip, where X represents the minor version number that you're about to package. Its'mandatory to come up with a zip archive, but you can come up with additional archives as well (e.g. .7z, .tar.gz or .tar.bz2) to make things easier for users on alternative operating systems.

• Upload the archive

  The archive(s) created in the previous step are meant to go into the download repository at https://sourceforge.net/projects/coppermine/files/. You will need packager privileges on the Coppermine project pages that reside on the sourceforge.net webspace.
  • Log in into your account on sf.net
  • Go to the File Manager
  • Expand the folder labelled "Coppermine"
  • Expand the folder labelled "1.6.x"
  • Click the "Add File" button
  • Browse to your package on your client and select it for upload
  • After uploading has finished click on the "i" icon in the uploaded package's row and set it as default download for all operating systems

• Publish announcement thread

  Move the announcement thread from the dev-only board to the announcement board. You will need moderator capabilities on forum level.

• Update cpg16x.files.xml on the Coppermine home page

  The xml file that contains the information about the most recent stable release needs to be uploaded to the official web space, replacing the file http://coppermine-gallery.net/cpg16x.files.xml that clients will connect to when checking for upgrades with the one from the Git repository (e.g. the file that corresponds to https://raw.githubusercontent.com/coppermine-gallery/cpg1.6.x/develop/include/cpg16x.files.xml). If you don't have access to the project's official webspace by FTP, ask a fellow developer to perform this task for you.

• Update the download button on the Coppermine home page

  On our Coppermine home page you need to update the URL and title of the download link as well as updating the button image itself.

• Create news items

  There are various news items that need to be created. They can all be filled with similar or even identical content, as they catter for different media or different ways to access the news.

  • News item on sf.net

    Create a news article on sf.net that contains a link to the announcement thread. To accomplish this, select, "News" from the "Develop" menu while being logged in with your sourceforge.net account. On the news page, use the "Submit" link to create a news item. The news item should contain a link to the announcement thread on the forum.

  • News item on forum

    Create a news item on the forum that contains a link to the announcement thread. You will need the corresponding priviledge on the forum.

  • News item on home page

    On the Coppermine home page, create a news item that contains a link to the announcement thread. Move outdated news items to the news archive.

  • News embedded into existing galleries

    To make users of existing galleries aware of the new release, edit http://coppermine-gallery.net/cpg16x_news.htm. This file is the source for the news item that is displayed for Coppermine admins on their galleries if the option Display news from Coppermine-gallery.net is enabled.

• Update the demo

  Use your favorite FTP app to update the demo on the Coppermine home page. You will of course need FTP access to the corresponding web space.
  Make sure not to overwrite the custom anycontent.
  Keep in mind that you need to apply changes to the JavaScript file script.js inside the localizations of the docs folder - they compose the site navigation.