webERP Forum

Full Version: Pending 4.15.1 release
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
Hi Paul, yes the release script will copy your data in it's entirety into the new demo data, so be careful that there is nothing in there you wouldn't want making public (your home address for instance might end up there).

I will look at what you say about the DB upgrade code a bit later when I have more time.

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. Smile (seems the move makes sense based on code flow)
Hi Paul, sorry for the delay I was ill yesterday so never got back in to look at this.

I am not sure it matters where this code is does it? Once it reaches that point if the upgrade is needed it redirects to UpgradeDatabase.php and then the whole session.php script gets run anyway. Though I may be missing something as I am still recovering Smile

Tim, no worries on the delay for me -- whenever you have time. Smile

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)
Hi Paul, in that case I would go for it. I certainly can't see any harm to it, and it looks as though you are right.

You need to take a decision on the changes Bob has sent in another thread. Should they go in this release or the next?

Another update:

The release is nearly done, I hit merge conflicts on many of the language (.mo and .po) files late last night, that I'll try to resolve tomorrow.
I did not realize the commit/update to the languate files early Sunday.

After correcting the merge conflict, the release will be ready.

Other than that, a test of a normal DB upgrade did fine.

Also, two clean installs of both weberp and weberpdemo databases installed all tables. (161 tables)
(06-10-2019, 02:32 PM)TurboPT Wrote: [ -> ]The release is nearly done, I hit merge conflicts on many of the language (.mo and .po) files late last night, that I'll try to resolve tomorrow.

Paul, these conflicts worry me they shouldn't be happening. Rafael updated the translation files just a short time ago. I think this is a consequence of what I mentioned before about him using slightly different commands to create the files now. I just worry you are bout to overwrite his work.

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.
To be honest the intricacies of gettext are a bit of a mystery to me. I just have this memory of the discussion with Rafael, and was concerned that whatever he did as a result of his work on it was going to end up being lost.

I agree with you that leaving his files in place is best, as I am pretty sure no new strings got added after his last update.

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.
  1. 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.
  2. 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:
  1. the xgettext command needs to have the same options, AND the directories processed should have the same order (path/name) in both scripts
  2. the msgmerge command needs to have the same options
  3. the msgformat command needs to have the same options
  4. when building the language references, the same branch should be used, whether that is head or some other branch to avoid file reference differences

Pages: 1 2 3