Rundeck GA version Compatibility - rundeck

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.

Related

Is there a "stable" version to use of the npm packages ui5/cli & sap-ux-tooling?

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.

which Spring Batch version is recommended for production, 4.2.7 or 4.3.3?

we plan to use Spring Batch for mission critical production batching system. And I am wondering which version we should choose now?
From the version history in github(https://github.com/spring-projects/spring-batch/tags): version 4.2.7 is marked with .RELEASE, while 4.3.3 is not.
So the questions are:
1、what's the difference regarding the versions with or without .RELEASE ending, is the ".RELEASE" ending verison more stable?
2、which version is recommended for production now ?
Thanks a lot!
Both are production ready releases, one for the 4.2 line and the other for the 4.3 line. I recommend using the latest 4.3 as it has an extended support lifetime. Spring Batch follows the same support terms as Spring Boot, and each version will be supported as long as the latest Spring Boot version that brings it is supported, see https://github.com/spring-projects/spring-boot/wiki/Supported-Versions.
For example:
the latest Spring Boot version that brings Spring Batch 4.2 is 2.3 which will be OSS supported until May 2021.
The latest Spring Boot version that brings Spring Batch 4.3 is 2.5 which will be OSS supported until May 2022.
etc
Spring Boot 2.6 is expected on November 2021 and will likely bring Spring Batch 4.3 as well, which extends the OSS support for Spring Batch 4.3 for another year. So I recommend using the latest version from 4.3 to benefit from a longer support period since you are planning to use it in production. FTR, there is an ongoing effort to update the website/wiki with all these support details across the portfolio, so keep tuned.
In regard to the version name scheme, we (the Spring engineering team) have decided to switch from the old naming scheme (.BUILD-SNAPSHOT, .RELEASE, etc) to a new naming scheme. This has been announced on our blog here: Updates to Spring Versions.

Can I publish a version older than the newest on NuGet?

Suppose I have version 1.1.0 on a NuGet server.
I then continue development and push version 1.2.0.
Then I find a bug in version 1.1.0 and want to fix this.
At this point, can I still push version 1.1.1?
There's nothing in the NuGet spec or protocol that prevents it, so it might depend on which NuGet server you're using, but I would be extremely surprised if any server forbids it because it would be so short sighted, in my opinion.
Using NuGet.Protocol on nuget.org as an example, version 4.9.3 was release in January 2019, but versions 4.8.2, 4.7.2, 4.6.3, 4.5.2, 4.4.2 and 4.3.1 were released in March, two months later.

which codeigniter version I should use production and deprecated function

I am having one codeigniter application with version 2.2.6. Is it good to use it in production OR I have to upgrade to 3.1
If YES how to upgrade? Version 3.x is still under development. What are the deprecated function (https://www.codeigniter.com/docs)
Its always better to use latest version for speed & security purpose.
But first you have to check your server PHP version, because CodeIgniter latest version 3.1.9 is not compatible with PHP 5.6
Your server must have PHP version 7.1 or 7.2 for CI 3.1.x
For upgrade CodeIgniter 2.2.6 to 3.1.x, you have to make few changes.
You can get steps for upgrade CI from here.
If your projects is not using deprecated CI functionality, then just replace "system" folder with latest version of CI will work.
My suggestion is to use CI latest version in production.

How to version a package containing multiple applications

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.