Right Way TO Keep Update Changes

Software Support
, ,
1

As you know, Ojs system will be update to new Version and its a real fact
and after each update i lose my new code for example: i add RTL to OJS 3.1 i want to know that how can keep this feature after OJS 3.2 or 4.X coming ?

is there any way to keep update change log in PATCH or some thing else?
please Guide and share your Opinion

Thanks in advance

2

I strongly recommend looking into using a revision control system, like Git, Subversion, or Mercurial. This will help you track and manage local code changes.

The PKP code itself is hosted on GitHub, so git is a common choice. For example, every time I upgrade OJS 2.x, I reapply the changes which use quoted-printable encoding for emails within the shared library, via the uls-add-quoted-printable-encoding feature branch:

The last three commits in that branch can be applied to each subsequent release.

3

@ctgraham i know that git works as Repository
but i want know how could i make for example Patch for change Date to Jalali ?
when ojs 4 comes i just need to run such Patch and done my job ?

4

For example, when I build a new release of OJS, I do a checkout of the latest OJS codebase and then a set of merges of my local feature branches:

# Clone PKP's latest OJS repo
git clone https://github.com/pkp/ojs
cd ojs
# Get a specific (new) release I'm customizing
git checkout ojs-2_4_8-2
# Attach my locals for OJS
git remote add mylocals https://github.com/ulsdevteam/ojs
git fetch mylocals
# Get any submodules
git submodule update --init --recursive
# Attach my locals for the shared library
cd lib/pkp
git remote add mylocals https://github.com/ulsdevteam/pkp-lib
git fetch mylocals
# Add my local changes back in
git merge mylocals/uls-add-quoted-printable-encoding
git merge mylocals/uls-css-disambiguation
git merge mylocals/uls-rename-taiwan
# Leave the shared library and back to OJS to add a local change there
cd ../..
git merge mylocals/uls-static-page-add-jbimages

This is a simplified example. The general idea is to have dedicated feature branches based on a common earlier commit which can be reapplied arbitrarily in the future. This may get more complicated and require either a git rebase or manual conflict resolution (and potentially challenging submodule merging) as the code changes get more complex.