Table count

[frostmakk]

Second try.

[frostmakk]

Nope. Still FUBAR.

[sozzled]

Hmmmmm ... I'll just edit (effectively delete) all my forum posts relating to this.

[mandville]

the only change i made was adding the name and then it threw the conflict branch and refused to do anything else.

[sozzled]

Well, no-one's blaming you, @mandville but, as I remarked earlier, I think that little things like choosing a new version number or codename are important enough to be done when a new PR is being developed (to distinguish the new test from anything else). That's just my opinion, of course.

I'm not sure what merit or value lies in retaining codenames (e.g. Lambrusca or Midden) but that's just a matter of personal preference and I don't really want to buy into such things.

We used to have these silly discussions about choosing codenames at the end rather than at the beginning when I was working on the Kunena project. AFAIK, the current practice (i.e. updating version numbers and codenames after all the other work has finished) continues to this day with K. Anyway, that's just personal preference.

But the version number is important. If there are changes to the code then a new PR should reflect the change by updating the v. number. Then we don't get confused what we're testing.

[frostmakk]

Merged now @mandville . Have a last look before I prepare the release.

[mandville]

i compared the code . it was an errant ")" that caused conflict on the naming wish GH would highlight that new one looks ok to me

[sozzled]

That's why I believe it's important to prepare a PR with all the changes (including updating the v. number and, possibly, the codename) at the same time as making other changes. Then we know (a) that the PR we're testing is different from the production version, and (b) that everything is in order to commit the change. Makes the process of version release a lot easier.

That's why I asked for those lines to be changed (to refer back to what @Webdongle asked before). A simple change but with an errant ")" can make a lot of difference to the confidence we may have that a PR is ready to go into production.

I'm pleased that the problem was quickly identified and we're all happy.

[Webdongle]

That's why I believe it's important to prepare a PR with all the changes (including updating the v. number and, possibly, the codename) So does that mean a change of version number every time a bug is fixed?

[sozzled]

Yes, @Webdongle.

Even if a PR is never released (and we have "gaps" in the version numbering), and a PR is cancelled, the history of the change(s) is not lost. It gets more complicated when there are several developers collaborating (on large projects) with several different branches in existence at the same time, but making sure that everyone knows what we're testing (and using the J! forum to test these changes) is clear. That's all I'm saying.

[Webdongle]

Version number changes should be made when the merged edits are released not when they are being merged.

[sozzled]

That's your opinion, @Webdongle, and you are entitled to express it that way. I have a slightly different opinion. The only thing I'm concerned with is having some confidence about what we're being asked to test.

Remember that our tests consist of taking the source code, copying it, creating a file on the PC, uploading that file to a J! website, running the script, copying the BBcode output and pasting in on the [phpBB] forum to see what it looks like ... if what we see is basically saying that we're testing the code that could be interpreted as relating to the current production version of the FPA then we may be committing something that is not what it should be. I just like to make things easy, that's all.

[sozzled]

As I mentioned before, this is one of those "arguments" I had when I was working with the Kunena developers. Sometimes the PR commit works and sometimes, as @mandville discovered a short while ago, it doesn't.

[Webdongle]

And my opinion is correct and you wrong

[sozzled]

If you say so, @Webdongle. I guess your opinion is probably the only one that matters.

I'm just a humble tester. What would I know after (nearly) 50 years in information technology, hmm?

[frostmakk]

Thanks for testing Kevin. Yes, you are correct. Thanks for all the noise Michael.

[sozzled]

You're welcome, @frostmakk. :)

You might find this information useful: https://freshservice.com/itil/itil-change-management-vs-release-mgmt-blog/

I'm ITIL-certified, BTW.

[Webdongle]

Yep that proves you wrong

[sozzled]

If you say so, Kevin. Looks like a case of Lions:10, Christians:nil. ;)