06-05-2019, 12:54 PM,
(This post was last modified: 06-05-2019, 01:03 PM by TurboPT.)
|
|
TurboPT
Administrator
|
Posts: 727
Threads: 10
Joined: Jun 2012
|
|
RE: Pending 4.15.1 release
With the last release, it was based on a clean (fresh install) copy of 4.14.1 to run the 4.15 script to update the DB.
(that is how I discovered that all of the tables were not created during install)
I did that intentionally (and this time around too) to avoid any possible "dev garbage" of mine, so I'm not sure of the password difference, and don't think anything unusual crept into the last release. (I don't see any dev garbage within the insert statements)
None of my general "dev passwords" worked either, so there's no telling what password is set. No worries, I'll ensure to update the reference, and test afterwards!
Thanks for checking the DB thing whenever you get a chance. (seems the move makes sense based on code flow)
|
|
06-06-2019, 12:25 PM,
(This post was last modified: 06-06-2019, 11:07 PM by TurboPT.)
|
|
TurboPT
Administrator
|
Posts: 727
Threads: 10
Joined: Jun 2012
|
|
RE: Pending 4.15.1 release
Tim, no worries on the delay for me -- whenever you have time.
Well yes and no on the code location...
Granted, it might not matter, but the "flow" of that handling was unexpected since the login was technically invalid.
I would have expected:
[Login] => [Invalid Login]
Instead of:
[Login] => [DB Update] => [No Session Error] (nothing about a bad login)
So, rethinking the picture, even my suggested move may not be enough to achieve the invalid login first, before DB upgrade, as it should flow.
This may be something to fix post-release?
I won't dwell on it, only an observation during testing. (and would only take the DB Upgrade flow if admin, I believe)
|
|
06-10-2019, 10:34 PM,
|
|
TurboPT
Administrator
|
Posts: 727
Threads: 10
Joined: Jun 2012
|
|
RE: Pending 4.15.1 release
I agree, and I'll keep Raphael's changes.
Most of what I saw were date/time diffs (between his run, and the run I did from make_release the day before), but there were some others.
It is curious, though, that a script Raphael sent me awhile back for his languages build seems to be the same as what is done in make_release, as far as the command, options, and directories processed. I'll take a closer look between the two, after release, to align any differences.
|
|
06-12-2019, 01:22 PM,
(This post was last modified: 06-12-2019, 01:38 PM by TurboPT.)
|
|
TurboPT
Administrator
|
Posts: 727
Threads: 10
Joined: Jun 2012
|
|
RE: Pending 4.15.1 release
Another update:
I emailed Raphael tonight about the language build differences. Turns out the diffs are many (about 30+ per file, at the same general places in all files), not just simple dates as originally perceived.
The differences are easy and we should be able to align the differences between the scripts so that the generated output is the same.
- The order of directories processed to xgettext are out of order between the scripts, so that makes the commented file/line# references out of order. (causing a diff) ... and make_release is missing 1 directory (as compared to Raphael's script) from the reportwriter/ path.
- The msgmerge command in one script uses --no-wrap, but the other does not, so that makes the other big diff. (which is many, if not most of the diffs)
Other than that, the texts and line#'s match, except for recent change to GLTransInquiry, which is in the release branch and not on HEAD, so the line# references are off a few lines for this file.
So, between the latter and the other 2 items, are what comprise the differences.
So to recap:
- the xgettext command needs to have the same options, AND the directories processed should have the same order (path/name) in both scripts
- the msgmerge command needs to have the same options
- the msgformat command needs to have the same options
- when building the language references, the same branch should be used, whether that is head or some other branch to avoid file reference differences
|
|
|