search

moodleou / moodle-mod_ouwiki

Alternative wiki module for Moodle 2 (designed for use in teaching and learning)
36 stars 33 forks source link

where can i find the source code for r3.11-r1 in this repo? #94

Closed stopfstedt closed 1 year ago

stopfstedt commented 1 year ago

Hi there, I'm referring to https://moodle.org/plugins/mod_ouwiki/3.11-r1/25581

Checking out the MOODLE_311_STABLE branch, I noticed that the release is behind (v3.9 r1 vs 3.11 r1). Digging deeper (diffing the download against the branch), it turned out that there differences more places than just the version file.

Please make the released code available in this repo. For context - we're deploying modules into our Moodle instance using git submodules, and this misalignment would require us to host the latest release ourselves in a repository.

Similar situation with https://github.com/moodleou/moodle-mod_oublog/issues/127

Best, Stefan

jason-platts commented 1 year ago

This repo does have the latest version ,if there are code differences then it would be the Moodle plugin database version that is out of date (we always upload to that from a download of this repo).

Note the named 'version' (r3.11 r1) on the moodle plugin database is not related to the version mentioned in the version.php - because the code rarely changes we don't routinely update the version.php but do update this value when adding and updates to the plugin database (also note that due to the annoying way the plugin database works you have to have an incremented version number in version.php to upload new code, which we often don't have so end up just changing the uploaded code which then causes people some confusion).

stopfstedt commented 1 year ago

Hey Jason, Thanks for the quick reply.

This gives me essentially two options:

  1. Accept the release from the Moodle plugins directory and version control it myself. Deploy from my own repo. Update my repo and redeploy whenever a new release appears in the directory.
  2. Accept whatever is at the HEAD of the current MOODLE_X_STABLE branch and move to a rolling deployment process from there.

Option 2 should be a no-go for production systems. There aren't even any tags that annotate milestones such as release points. Option 1 works, but creates overhead that could be avoided if release and source control were in alignment. You see my problem here?

I understand the annoyance with having to bump version numbers when releasing repeatedly. But I don't understand you point about preventing confusion with your current process - I'll argue that distributing releases that cannot be mapped (at least not easily) to their version controlled source is what's causing confusion here.