Wrong release number in 1.10.4 tarball

Bug #1463630 reported by Takahiro Sumiya on 2015-06-10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Aaron Wells

Bug Description

In the archive mahara-1.10.4.zip and mahara-1.10.4.tar.gz, each 'lib/version.php' has release number '1.10.5testing'.

 $config->release = '1.10.5testing';

This may be wrong number, and I wonder if some 1.10.5testing codes contaminate in 1.10.4 archives.

Aaron Wells (u-aaronw) wrote :

Hi Takahiro,

Thanks for reporting this bug!

There were some complications during the 1.10.4 release process, and I wound up having to do part of the release by hand instead of using the automated scripts we usually use for releases. It looks like while I was doing that, I accidentally changed the release string to "1.10.5testing" one commit early.

The good news is, this is just a labeling mistake. The actual code in the zip package, (with database version 2014092319) *is* the correct code for 1.10.4. It's just the human-readable release string that's incorrect. So this will have no effect on the actual operation of your Mahara site.

Nonetheless, I'll repackage the release with the correct release string, to avoid confusion.


no longer affects: mahara/1.10
Changed in mahara:
milestone: none → 1.10.4
assignee: nobody → Aaron Wells (u-aaronw)
importance: Undecided → High
status: New → In Progress
Aaron Wells (u-aaronw) on 2015-06-11
summary: - wrong release number for 1.10.4?
+ Wrong release number in 1.10.4 tarball
Changed in mahara:
status: In Progress → Fix Released
Aaron Wells (u-aaronw) wrote :

Okay, I've uploaded new 1.10.4 release packages that have the correct release string. So now if you download the releases from Launchpad, they will read "1.10.4" instead of "1.10.5testing".

I've also bumped the database version number, so if you replace your erroneous "1.10.5testing" packaged install with this new package, it will change it to read "1.10.4".

(On the git side of things, there actually hadn't been any further commits in the 1.10_STABLE git branch since the 1.10.4 release, so I took care of this in the git history by adding a new commit to the top of the 1.10_STABLE branch which bumps the DB version and changes the release string from 1.10.5testing to 1.10.4. I then moved the 1.10.4_RELEASE signed tag to point at this new commit. Lastly I created another commit that changes the release back to 1.10.5testing and bumps the DB version again. I considered doing a git push --force to get rid of the erroneous commit from our history, but I decided against it because it might make future merges just a tiny bit more complicated. Of course, git doesn't really support moving tags around, so anyone who has already fetched the old 1.10.4_RELEASE tag will not see the new one. But that's not such a big deal.)


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers