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.
Related
To my knowledge, the latest non-alpha version of the #ui5/cli and #sap/ux-ui5-tooling (as of 2nd March 2022 - version 2.14.6 and 1.5.0 respectively) are the ones to use.
However, I wanted to confirm as my organisation has multiple ui5 projects and so having a standardised version of the #ui5/cli and #sap/ux-ui5-tooling dependencies could prevent issues around bugs in tooling.
If the advice is just to use the latest non-alpha version, then I just need to update the dependencies regularly.
The versions you mentioned should be your choice to use in a productive environment.
The upcoming UI5 tooling 3.0 is not.
I don't think you will achieve the same version in every app because of the lifecycle.
The packages are fast paced and when u have a stable app deployed you will not update it every month I think.
I would not invest time to find the perfect tooling version.
I'm totally confused about the release numbering Unity is using. Looking at GitHub, I see that the latest release is referred to as 'Release 17' yet the version numbers when looking at things in Package Manager look like 1.08.
Is Release 17 the same as 1.08? Could someone clarify that.
Also, I downloaded Release 17 and installed it by referencing the package.json file however, Unity show it up as 2.0.0
I hope you guys can help.
thanks
Based on Unitys docs about Versioning I would guess that the overall count of releases is 17, meaning there have been 17 public releases of the package. There is usually a change log that you can find using the package manager that goes into a little more depth for each version. I would guess that the github has more versions than the package manager as the versions released on the package manager are most likely more stable and not just hot fixes.
To summarize, they've had 17 releases, some could have been before version 1.0.0 and you mentioned that 17 is 2.0.0. It could be that 2.0.0 is not stable yet which is why you need to download it from Github to have it in the package manager. Anything prior to the first digit is a patch release version increase. So with 1.0.8, it means they're on major release 1 on patch version 8. The other reason 2.0.0 might not appear in your package manager is due to being on a non verified version of Unity for this package version or not viewing unreleased packages. It could be 2.0.0 works, but is not verified by Unity yet on your Unity version.
Currently I am using Rundeck 3.0.23-20190619.
Whether Rundeck 3.0.23-20190619 is stable version?
From the https://bintray.com/rundeck/rundeck-rpm/rundeck able to see the Rundeck 3.0.23-20190619 is not yet published as GA.
2.11.14-1.70.GA is the latest GA version with build date 2019-09-13T03:37:04.000Z.
Will the application developed with 3.0.23-20190619 compatible with 2.11.14-1.70.GA?
Right now the latest stable release is 3.1.2, you can check the latest version in the changelog here. The "GA" notation is not used anymore. In some cases, you can see some updates of 2.11 / 3.0 branches focused on backports, not for new features, etc.
Your projects and jobs are compatible using 2.11, 3.0 and 3.1 branches.
I have a few apps (already working) running parse-server on Heroku and using mLab mongoDB.
I need to upgrade parse-server to a new version.
What is the simplest (an best) way to do that?
Ensure compatibility by testing locally first, of course. To upgrade the version you change your project's package.json file. There should be a dependency "parse-server": "a.b.c"
"a.b.c" will use an explicit version.
"~a.b.c" will use the latest version matching "a.b."
"^a.b.c" will use the latest version matching "a..*"
a is a major version, which is not always backwards compatible.
b is a minor version, which generally includes new features but should be backwards compatible, so ^ is usually safe to use.
c is a patch version, which is generally bug fixes and security updates, though I think parse-server has included minor feature updates here as well.
I am trying to update my product to a later version. Let's say product I am trying to update is at version 1.0.0 and there are two update sites available, one that has version 1.5.0 and another that has 2.0.0. Both update sites are in the update site manager. When I click "Check for Updates" I find only version 2.0.0, not 1.5.0. If I disable update site for 2.0.0 then 1.5.0 shows up during update check. Is there a way to control what updates make into available updates? Is there way to make it so both 1.5.0 and 2.0.0 show up so I can choose?
The short answer is "no". The check for updates feature is not designed to give user a selection of versions. In Juno and earlier, it will attempt to update to the latest known version and fail if that's not possible. In Kepler, it will attempt to update to the latest version that can be installed given system constraints, so the update is more likely to succeed. In either version, the user doesn't get to pick among versions when updating.