Hi Community,
My app is compatible (tested) with Confluence versions from 7.13.6 to 9.02. What values should I use for the ‘confluence.version’ and ‘confluence.data.version’ properties?
1 Like
My understanding is that its related to what database schema updates need to be performed when the instance starts. So it depends what version your generated-test-resources.zip file was created on.
confluence.version: version of Confluence that you want to launch
confluence.data.version: version of Confluence that the generated-test-resources.zip file was created with.
So generally the test resources zip will be created from your oldest supported version, and then you can set the Confluence version to whichever version of Confluence you would like to develop against.
I think there are some Confluence versions where the upgrade from old test resources always tend to fail, (7.8.0 comes to mind) in which case you cant have the test resources from <7.8.0 and confluence.version >7.8.0
1 Like
Dear @becker ,
You define the compatibility of an app in the app‘s settings on Marketplace.
The versions you define in the POM are used by Maven to identify the code basis of Confluence you want the compiler to check against. From my experience there is no right or wrong here: in case you use a very old basis you won’t catch depreciations or changes during compile. If you use a very new version you might use functions not existing in older versions of Confluence.
I hope that helps.
Andreas
1 Like
One thing that I find a bit annoying is that setting confluence.version only (and not changing confluence.data.version) doesn’t update version shown in the footer when the development server starts (atlas-run).
So (if my understanding is correct) the version shown in the footer matches whatever confluence.data.version was when the /target directory was populated after it was previously cleaned (atlas-clean).
We have developed a habit of setting both properties to the same version and running atlas-clean whenever they change, just to be sure that the version displayed in the footer reflects the current running version. (This habit was formed a number of years ago, so it is possible that this advice is outdated). We’re lucky that we don’t need a lot of persistent state in our dev setup, so running atlas-clean frequently is not too much of an impediment for us.
In terms of compatibility, we generally set both properties to the latest available Confluence version to be sure our app compiles and runs against each new version as they are released, and only test against older versions if we make significant changes to package imports.
Whether this is a good practice or not, I don’t know, but it seems to work for us.
1 Like