Should the "master" branch be the last stable one?

Software Support
, ,
1

Hi,

Today I just realized that pkp’s master’s branch is not running the last stable ojs version…

Is there a good reason for this? “Master as the last stable” is the usual case for most projects and this makes possible to create a docker image that always start the right (stable and up to date) production stack.

Otherwise, if for some reason, this change is not possible… Is there an tag or branch to get the right code? I mean, if branch names are versioned (ie: ojs-stable-3_0_2) we will need to keep versioned docker images and this is not a good idea.

To explain better the problem take a look to this docker file (tagged as “latest”):
https://hub.docker.com/r/marcbria/docker4ojs/~/dockerfile/

There, when we “git clone” we get “master”:

&& git clone -v --recursive --progress https://github.com/pkp/ojs.git /var/www/html \

So the question is: what branch/tag need to be pulled to get always the right version?

Cheers,
m.

2

We can set the default branch within GitHub. Most other projects I know (Islandora, Drupal modules) use the master as the current development head, and use dedicated releases for “stable”.

Can you point us to some examples of projects that maintain a “stable” master?

3

Hi @ctgraham,

As usual, you are right. :blush:

As you say, most of the projects work as follows:

  • stable: Accepts merges from Working and Hotfixes.
  • master: Accepts merges from Features/Issues and Hotfixes

When there is no “stable” branch, I wrongly assumed that master is the stable one.

The point is, if we don’t have canonical names for production branch (it means: “stable” instead of “ojs-stable-3_0_2”) we will need to keep up to date docker/vagrant/etc. scripts on every release and this don’t make much sense.

So the right question here is: Why we don’t keep an “stable” branch?
(or a “production” if you prefer?[1])

References:

PD: pkp’s branching model should be clarified at the begining of this documentation:
https://pkp.sfu.ca/wiki/index.php?title=Github_Documentation_for_PKP_Contributors

4

Hmmm… +1 from me. This would align us better with other projects.

Something like branches:

  • master
  • stable-3.x
  • dev-2.x
  • stable-2.x

Thoughts, @asmecher?

5

Hi all,

We have maintained additional branches before, but for the moment I’m hesitant to re-introduce that because of the huge amount of cherry-picking it’ll require. If we could somehow point a more general “stable” alias at the most recent abc-stable-x_y_z branch, that would be a good solution. It’s possible that Git offers something like this.

Regards,
Alec Smecher
Public Knowledge Project Team

6

Yes @asmecher, looks like git offers aliases for branches:

I like @ctgraham 's naming proposal, but I still miss a general “stable” branch without any version information.

Cheers,
m.

7

Hi all,

I could use aliases for either stable-2_x/stable-3_x, or just one stable one, but I’m wondering about use cases. It wouldn’t be good for ongoing use, I don’t think: presumably when a new release comes out we’d move the alias e.g. from ojs-stable-3_0_1 to ojs-stable-3_0_2, and anyone hosting on that alias will suddenly be forced to perform an upgrade when perhaps they had gotten used to small fixes getting cherry-picked in. Who will this serve, and how?

Regards,
Alec Smecher
Public Knowledge Project Team

8

I would propose eliminating the branches which explicitly name stable minor releases.

Tag every minor release, as we already do, but maintain only [product]-stable-3.x and [product]-stable-2.x. Host and set docker/vagrant images off of these.

Ideally, we should target frequent minor releases, so there there is almost never a delta between stable and the most recent minor release.

9

Hi @ctgraham,

PKP’s own hosting services make heavy use of the specifically-named stable branches (e.g. ojs-stable-3_0_2). The way that we maintain branches means that you can always refresh an installation to the latest on that branch without needing to e.g. run an upgrade script. (Essentially, these replace the old “recommended patches” list we used to maintain – ojs-stable-3_0_2 is the same as ojs-3_0_2-0 plus recommended and non-invasive patches and fixes.)

Regards,
Alec Smecher
Public Knowledge Project Team

10

I don’t see any problem in keeping more branches and others can benefit of this specifically-named branches.

So to be clear, the proposal is creating the following “alias” branches (symbolic-ref) as follows?

  • stable: the last stable version recommended by PKP for production use (right now is ojs-stable-3_0_2)
  • stable-3.x: the last 3.x stable (-> master)
  • dev-2.x: the last 2.x dev (-> dev-2_4)
  • stable-2.x: the last 2.x stable (-> stable-2_4_8)

Do we all agree? @asmecher, is this feasible?

Thanks in advance,
m.

PD: I’m on vacations now, but still playing with docker4ojs when I get wifi connection. Docker is fun. :wink:

11

Hi all,

I haven’t played with the aliasing options, but yes, I think that sounds plausible.

For naming, I would suggest aligning punctuation with our current conventions, i.e. stable-3_x instead of stable-3.x. The dev-2_x branch would be essentially moribund, so I suggest omitting it.

Since we’re planning to go to simultaneous releases for the 3.x suite of apps, hopefully we can avoid prefixing any of these with the app names as we’ve had to do in the past. And the 3.1.1 release, which is where we’re currently planning on making the switch to simultaneous releases, seems like a logical time to do introduce these.

Regards,
Alec Smecher
Public Knowledge Project Team

12

Could we also keep a non versioned “stable” (or “production”) branch as explained before?

Cheers,
m.

13

Hi @marc,

Yes, that should be easy enough to add – but frankly I’m worried about its use landing people in unexpected trouble. I would expect a stable branch to be something I can pull from whenever I need to without suddenly landing in a broken installation. If we change stable from, say, ojs-stable-3_0_1 to ojs-stable-3_0_2, then immediately upon pulling, everyone using stable will need to run the upgrade script (and go through the upgrade process) before their installs will work. That’s why I’ve leaned towards specifically-versioned stable branches.

Regards,
Alec Smecher
Public Knowledge Project Team

14

This will also happen with the generic “stable-3.x” or “stable-2.x” branches @ctgraham pointed, isn’t it?

I was thinking in adding an “$ php tools/upgrade.php upgrade” every time I rise the docker container… combined with good backup policy (snapshots), but I suppose this kind of automation will make SysOps guys a little bit nervous. :slight_smile:

I don’t know @asmecher … I understand your concerns, but I also can see benefits.
Right now, from git is not clear what branch should I pull for my production site.

1 Like
15

So, the branches will be the ones listed here except the generic “stable”, isn’t it?

If you confirm this I will create the corresponding docker images and update the pkp wiki page with the branch descriptions.

Cheers,
m.

16

Hi @marc,

I’d like to leave this change until the 3.1.1 releases of both OJS and OMP. At that point we won’t have to worry about tagging the application name; currently we’d have to include that.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
17

Dear @asmecher,

I was wondering if I want to update my server with the latest OJS 3 including all the changes made till date, what should I use. suppose I do not install from GIT. I download files and upload to server.

Regards,
@anupent

18

Current stable version is “ojs-stable-3_0_2” but a new stable will be released soon.

Yesterday I updated this post with git instructions, because is where google drives you when you search for “git ojs”:

(Thanks Clinton for the fixing in the version spelling :stuck_out_tongue: )

In short, if you have git and composer installed, to get the last stable do this:

$ git clone -v --recursive --progress -b ojs-stable-3_0_2 --single-branch https://github.com/pkp/ojs.git /your/destination/path
$ cd /your/destination/path//lib/pkp
$ composer update

If it didn’t work, open a new post in forum, please. :wink:

1 Like