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.
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.
Is httpclient-4.5.2.jar backward compatible with httpclient-4.3.6.jar?
Same question also for httpcore-4.4.4.jar with httpcore-4.3.3.jar?
I have to use a newer version for supporting some functionality. but is there any impact of my older code?
Is those jar version controlling working conventional way for backward compatibility support like java JDK?
Short answer no. For minor upgrades (4.3.3 to 4.3.4) things usually work, but when you go from 4.3 to 4.5 you can expect changes. See release notes for hints about what you can expect.
Having said that, if you can compile without errors you are usually safe!
I understand that NuGet packages update process is not automatic for a good reason (a new version could break your code or cause unforeseen problems), but then it transfers the responsibility of updating all packages to the developers themselves. When exactly should we be updating NuGet packages for a given project? Are there some guidelines regarding this process?
In our current project, this is more or less arbitrary: I update packages whenever I remember to check for updates, and preferably at the start of a sprint so that, if there are problems with the newer versions, we are able to fix them or rollback to the previous versions of the offending package. Most of the time, I'm the only developer that worries about this stuff, but I feel it is valuable to always be as up to date as possible because of performance reasons and new features that can make our work easier.
Well, you should update whenever you are able to cope with it.
So you need to think carefully about the regression updating the packages could cause to your application if already in production, or the extra tests you are going to need to carry on in order to verify everything seems to be working as expected.
Normally updating to newer minor versions shouldn't cause much problems, but you always have the risk of it. Looking at the newer version release notes could prepare you to what to expect of the update.
In summary, update when you can cope with it, and you are ok with any shouting from your testers if suddenly the system regress without them even knowing it was coming :)
Few tips to decide package update strategy:
Don't run production application on a deprecated (not-maintained) package version. Upgrade to a maintained version at bare minimum if unable to upgrade to latest.
Don't run production application on a pre-release (not-stable) package version. Upgrade to a stable maintained version.
While upgrading by a major version, read publisher's release notes to understand the implication backward-compatibility from application context. This will help put a better estimate on development and testing efforts.
I am upgrading my server from an old version of Mercurial, 1.5 to the newest version. I am wondering if the 2.2 build of Mercurial is stable for use by multiple users at a time. Also are there any gotchas when upgrading like my custom hooks not working, or a buildslave object not working? I have not done a major upgrade on a source control server before so help would be appreciated.
Mercurial is famouse for being very strict regarding compatibility. Have you checked upgrade notes? It list all breaking changes between version. Biggest change for me is introduction of hgweb in 1.6.
Biggest exception from compatibility rules are hooks. Mercurial doesn't guarantee anything so only way is to try.
Also consider making update in two stages. For example first to 1.9 and than to 2.2.
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.