I wanted to get started with kafka ( i had little experience with kafka 0.10 , and now, it seems there are "major" changes happened)
I am going through release changes of kafk. However, I am stuck with which version I should choose in terms of stability , community support . I am little reluctant to use the latest version 2.5
Please suggest me a version which didn't get a lot of "major" changes . I heard kafka 2.1 is good start as it had some breaking changes from previous version .
If you're making the leap from 0.10, I don't see any point in stopping part-way with 2.1.
In terms of releases, the latest stable release is 2.5.0. If you prefer, 2.4 was released in December 2019 and has had a dot release since (2.4.1).
Check out this excellent talk which addresses why you should upgrade.
I didn't find a lot of material about 2.5
The majority of material is version agnostic (unless it's based on super-old versions, like 0.10 etc). If you want to see breaking changes specifically, look at the download page which notes major changes and links to the release notes for each version which lists every single 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.
We are planning to use Drools in our organisation with Scala/Spark. We have selected Drools Version 5.3.0 and 7.15.0 for our use but we have some stability doubts between them because Version 7.15.0 has recently launched & we are not sure whether it is stable or not.
We have practiced with Version 5.3.0 but we want to know the life cycle of it. What if after some time, Version 5.3.0 will not available for use or some update is brought for this?
So please help us to chose between them which version should we chose for longer use.
Drools 5.3 is outdated version and its not under development. Its better you go with latest release.Drools 7.15 is also stable, but if you are planning to use it for business critical application then I will recommend you to go with enterprise release of Drools 7.x , i.e Red Hat Decision Manager. With enterprise release will get patches for known issue on regular basis and one-off patch for critical issues.
I am seeing 2 versions (9.0.1 vs 8.2.1) of wildfly which were released on the same day. What is the difference between two versions and why there are 2 versions exist in parallel? I couldn't find it over the internet.
Wildfly ships on a very fast development cycle. Each major release 8.x, 9.x, 10.x contains major changes from the previous version. All current major work is being done on the 10.x beta versions.
The minor versions are for bugfixes related to that particular release. Since there are now people in production with both 8.x and 9.x, any critical bugs or security patches go into one of these releases. It is very possible a security issue could exist and be fixed in both 8.x.1 and 9.x.1.
JBoss EAP, which is based on WildFly, deliberately has a slower release schedule. For each major version they release they offer paid support for 4 years, so they change major versions much slower.
There is a good slide of the lifecycle of WildFly/JBoss on page 9 of this slide-deck from the RedHat Summit in June:
http://videos.cdn.redhat.com/summit2015/presentations/12186_red-hat-jboss-enterprise-application-platform-7-roadmap-new-features.pdf
Here is the official announcement for the pair of releases: -
http://wildfly.org/news/2015/07/23/WildFly-901-and-821/
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.