Curious about OJS development cycle

Hey there!

First of all, thanks a lot for OJS. It is a great tool! For a year I have been the person responsible for OJS deployment at CERN. Just recently, I managed to clean up the deployment and have proper CI/CD. I based the deployment on stable-3_3_1 branch which seems to be a bit behind the current production release. I incorrectly assumed that it is the latest working version. Therefore, I would like to ask you to describe your development cycle because just looking at the git history didn’t give me any clear answers. So I have the following questions:

  1. What is your branching model? For example, I see that stable-3_3_1 is a bit behing the 3_3_0-8?
  2. How do you decide the branching point for a new branch?
  3. Do you cherry-pick commits between branches?

Thanks a lot for every answer that will help me understand how you keep different versions/tags available.

Regards,
Michal

1 Like

Hi @crossner90,

You can check our release plans at Roadmap - Google Sheets (second tab over) – we had planned a 3.3.1 release (hence the moribund stable-3_3_1 branch) but mothballed it in favour of going directly to 3.4 in Q1 next year.

The latest currently supported stable branch is stable-3_3_0; you should be ok to rebase on that from the current stable-3_3_1. I’ll clean up that branch to avoid further confusion.

Thanks,
Alec Smecher
Public Knowledge Project Team

1 Like

Hey @asmecher ,

thanks a lot, however this doesn’t give me any insight into your branching model and I can’t find anything about it in the OJS documentation. I am really curious what strategy you have when creating new release branches etc. Is it described somewhere?

Regards

Hi @crossner90,

You caught me on a weekend :slight_smile: so here’s a more complete response:

The current “development” version of the software is always found on the main branch. This should never be considered stable. At the moment we are preparing to release this as OJS/OMP/OPS 3.4.0, at which point we will create a corresponding stable-3_4_0 branch and main will evolve towards the next major release, which will be 3.5.0.

If we need to release software with breaking changes before 3.5.0 is due for release (e.g. because a grant’s timing requires it) we may opt for a 3.4.1 release (and accordingly a stable-3_4_1 branch). We try not to do this if we can avoid it, because it means lots of cherry-picking of changes to multiple branches (main and stable-3_4_1 for new features, and at least main, stable-3_4_1, and stable-3_4_0 for fixes), which is a lot of work to do and risk of introducing regressions. This is the situation you caught us in when you started using stable-3_3_1 – the branch was created but the software was not yet released, so the branch was in limbo.

You should always be able to find the latest stable branch by looking for the newest release of the software on the download page (currently 3.3.0-8) and finding the corresponding stable branch (stable-3_3_0).

Thanks,
Alec Smecher
Public Knowledge Project Team

1 Like

Thanks a lot for the answer, that is very helpful!

1 Like