Can I install an older version of confluence and is a Confluence DB having 3 build numbers OK?

[James Malgieri]

I work with 2 JIRA/Confluence server instances. Inst-A, which I do not control and Inst-B which I have full control over.  Inst-A has been using long term release versions while in Inst-B I had been been trying to keep up to date with the latest license versions though Inst-B did fall out of use for at least 6 months.

Recently, I was asked to get Inst-B working again and matched version-wise with Inst-A which means, for Confluence, installing a lower version than was already installed.

1) On Inst-B, I installed Confluence 7.4.8, build number 8402. However, I replaced 7.8.x,, build number 8502.   Now my confluence.cfg.xml and database CONFVERSION both show 8502.  I thought I could manually edit confluence.cfg.xml and use the SQL

UPDATE CONFVERSION 
SET VERSIONTAG = NULL, 
BUILDNUMBER = 7201
WHERE CONFVERSIONID = 4560123456;

using 8402 for the BUILDNUMBER and CONFVERSIONID 13959171

as explained in  

https://confluence.atlassian.com/confkb/confluence-will-not-start-up-because-the-build-number-in-the-home-directory-doesn-t-match-the-build-number-in-the-database-after-upgrade-376834096.html

Does this seem reasonable or should I go about it a different way?

2) Running

select * from CONFVERSION;

shows me there are 3 build numbers in our confluence database, please see above picture.  Is this "normal"? Should I delete 2 of them so there is only 1 build number in the DB?

Thank You for your help,

Jim

[Nic Brough -Adaptavist- · Accepted solution]

You should not be messing with the numbers in the database (in fact, just don't even look at the database)

More specifically, in this case, you say "which means, for Confluence, installing a lower version than was already installed.".  Nope, don't do that, downgrades often completely fail and mess up the data in interesting ways.

[James Malgieri]

"You should not be messing with the numbers in the database (in fact, just don't even look at the database)"  

Nick, I'll gladly not look at the numbers in the database!

" . .  often completely fail and mess up the data in interesting ways."

I think "Interesting ways" actually means you'll wish you never, ever tried to downgrade.

OK, Nick.  I'll take your advice.

Thank you for your reply. I truly appreciate it.

Jim

[Nic Brough -Adaptavist-]

To be fair, sometimes, it can work (most important is that the database structure has not changed between the current and older version).  But it's a world of hurt getting it there and being 100% sure everything is ok.

Absolutely right about "interesting ways" - the one that taught me that lesson was not so much a downgrade attempt that broke anything day-to-day, it was that a year later, it had rendered the Confluence completely un-upgradable - it failed no matter what version it went to.  Ended up having to manually export and import 450 spaces, one at a time, and then redacted the handful that could not be exported because of the break!

[Nic Brough -Adaptavist-]

Oh, and I forgot - the technical reason that there are three lines in the database for version is simply that those are the upgrades that this Confluence has been through at some point!

Those are not strictly upgrades triggered by an admin, a lot of the upgrade packages actually don't re-invent any wheels, internally they trigger a string of pre-existing upgrades.   For example, you've got 8202, 8301 and 8502 builds in there.  If you've jumped from 8202 to 8502, then the code for 8502 includes the code for an 8202 -> 8301 and 8301 -> 8502, so when you asked it to upgrade, it just went "ok, I'll chain two upgrades together".