I have a similar issue to others with version numbers in the App Store being unable to upload but don't see a solution for mine.
I created version 1.21, which is a published app. I now realize that the format is supposed to be 1.2.1
Then I tried to create version 1.3 but it says the 1.21 is higher.
How can I get back on the 1.x version numbering format?
Thanks in advance,
~eric
~eric
1.21 is obvisously higher than 1.3.
I think your only option would be version number 1.22 or higher.
Related
Is there a postgres and keycloak version compatibility matrix? What is the latest postgres version compatible with Keycloak 20 ?
Unfortunately, there's no any matrix. In docs just a short and outdated list and some comments in Github discussions on why it's outdated.
Meanwhile, DB version for Java apps always depends on JDBC driver version.
So, the easiest way to find out what version of PostgreSQL is suitable for KC release is to take a look at versions of JDBC driver and PostgreSQL that specified in pom.xml. Switch to a release tag in the official repository, e.g. https://github.com/keycloak/keycloak/blob/20.0.3/pom.xml#L149-L150
The documentation here suggests Version 10.
The developer commits and issues only mention postgresql without versions. It doesn't matter which version you use, as long as it's supported!
See here for supported versions:
Supported versions
If I upgrade the angular version of my project to the latest one, do I need to upgrade my ag-grid version also to the latest one to make it work? Or, my ag-grid will work without any change?
Generally, an old version will work without change.
I'm currently using version 20.2.0 with Angular 8 (the current ag-grid version is 23.1.0).
I'm not sure what will happen if you try to use an older version with Angular 9, using the Ivy Renderer. I expect that it will work ok, but I haven't tried it yet.
I am not able find any related information regarding to my current situation. Is it possible to use the Oxygen 14.1 xml author with DITA-OT 2.5.2? We plan to upgrade our sofware too, but before that the leaders of my company are interested in the possible benefits of the new DITA-OT version.
For testing purposes you can try using an oXygen 19.0 trial (https://www.oxygenxml.com/xml_author/register.html). I don't think oXygen 14.1 will work too well with the newest DITA-OT. Maybe yes, maybe not... But if you plan to upgrade to 19.0, there's no need to try 14.1 with DITA-OT 2.5.2. Just try the oXygen + DITA-OT pair that you are planning to use.
You could try using the new OT with oXygen 14.1. I believe that you'd have to create versions of the transforms to point to the new OT. However, you won't be able to use any DITA 1.3 features unless you extend the oXygen framework to pick up the newer DTDs. Probably more work than using a trial version of 19.
I am facing a problem. I have upgraded my moodle database from 1.9 to 2.7.1. After upgraded from old to new version, some of table structure are changed. I am not getting user who enrolled in courses after upgrade. Please help me to sought it out.
When upgrading Moodle from a version to a newer one, you should always do it step by step.
This means, you should avoid jumping major versions between yours and the newest one.
In your case, this is even more complicated, because Moodle 1.x is very different from Moodle 2.x.
You must first upgrade your Moodle 1.9 to Moodle 2.0.x.
Then, after checking that everything's fine, upgrade your Moodle 2.0.x to 2.1.x.
Repeat the same for every major version (2.2, 2.3, 2.4, 2.5, 2.6 and then 2.7).
Doing this, you avoid crashing your database because of major modifications.
Check out the official doc for more informations about it : https://docs.moodle.org/20/en/Upgrading_to_Moodle_2.0
I want to create an MSI installer containing three apps. I will be releasing frequent updates to each app as I work through the list of feature requests and do bug fixes. The three apps are currently at versions 1.6.3, 1.6.12 and 1.8.1 respectively.
I was wondering what you guys can recommend for the version of the package. Should I:
Make the package version independent of the versions of the individual apps ?
Change the apps so they always have the same version as each other ?
Some other suggestion ?
Modify the package version each time the version of one of the apps changes. Then, you can look at the package version and know exactly which version of each app was being used.
Example:
Main version 1.4.1 has (1.6.3, 1.6.12, 1.8.1)
Main version 1.4.2 has (1.6.3, 1.6.13, 1.8.1)
Main version 1.5.0 has (1.7.0, 1.6.13, 1.8.2)
Main version 2.0.0 has (1.7.0, 1.6.14, 2.0.0)
So, if you're doing a minor version upgrade to one of your apps, the main application also goes up by a minor version number. Major changes to a sub-app result in the main app also getting a major version number change.