I am looking at Nexus 3.00 OSS Edition.
The recent release of Nexus 3.0 (OSS Edition) seems to have dropped support for rpms.
I don't see any specific note declaring that they are going to be dropping some features from 2.x.
So i am not sure whether the rpm/ yum repositry support is actually removed Or is it being supported differently with the new Nexus 3.0 or this feature has been made exclusive for the Paid version.
Not yet. The progress of this can be tracked in http://issues.sonatype.org/browse/NEXUS-10191. Feel free to watch for release details.
Related
Currently I have a single DC cluster with 3 nodes running 4.1.7 version of Scylla. This setup has been running for a long time and I don't want to make changes to this DC, if possible. Now I have a requirement to add another DC cluster with 3 nodes. Can I set up this new DC with the latest stable version of Scylla? Will the two DCs be able to communicate with each other without any issues? Or am I forced to upgrade the existing DC to the latest version?
Scylla supports rolling upgrades, which means you can indeed upgrade just some of the nodes in the cluster while the rest are still running the older version. The cluster should be able to fully work in this state - including the communication between old and new nodes. Not all upgrade paths are equally supported or have been equally tested, obviously, but most "interesting" upgrade paths (a newer release in the same major version, the next major version) are indeed supported.
That being said, while staying at a half-upgraded state for a long time is possible, it is not recommended. It also means that whatever new features or improved algorithms were introduced in the new version, the new nodes will need to avoid them until the full cluster is upgraded.
OSS 4.1.7 is a pretty old OSS release from Oct 2020. The assumption that you can add another DC running OSS 5.0 (latest OSS release from 10 days ago) to the existing cluster, is a bit of a risky one.
The supported upgrade path (QA tested) is from OSS 4.6 to 5.0. You can read more about the upgrade path here: https://docs.scylladb.com/upgrade/upgrade-opensource/
The tested upgrade route is via minor versions 4.1 --> 4.2 --> 4.3 --> 4.4 --> 4.5 --> 4.6 --> 5.0, jumping multiple minor version should work, but we can't say that it was tested.
There are multiple versions of IBM mobilefirst platform available. What are the different decision points that need to be considered for choosing a particular IBM mobilefirst version for implementation?
There are only two versions that should be considered at this time: 7.1 and 8.0, and the only reason to choose 7.1 is if you've already invested in a version older than 7.1. The reason I say that is because V8.0 is rearchitected in a number of significant ways that make it more suitable for Cloud deployments and Open development models. Therefore, the cost to migrate from an older version to V8 is somewhat greater than to migrate to 7.1, and 7.1 will continue to support all the latest mobile operating systems. V8 on the other hand has many new features that 7.1 will never have (as you'd expect) If you're looking to play with the technology, go download the free DevKit from https://mobilefirstplatform.ibmcloud.com/.
So bottom line: If this is a new deployment/purchase/etc. then I'd always suggest V8 as the preferred choice. However if you already have an investment in older versions, V8 is still the preferred choice, but migration to V8 may take more time than to migrate to 7.1.
Does that answer your question?
Mobilefirst 7 or 7.1 will be most reliable as of now since it has been in the market for some time and most of the pmr's would already be resolved. Within 7 and 7.1 itself there are few changes like 7 has desktop browser environment which is not present in 7.1. So you would want to check out the differences before chosing 7 or 7.1. But personally I would recommend you to go for mfp8 since there are lots of new features added into it. It might be a bit unstable but eventually everyone would upgrade to 8 is what I feel.
I'm starting to use redis for my applications as a cache backend and "shared memory" store.
I've asked the servers maintenance team to install Redis on our CentOS 6.5 production environments. From EPEL, the version is 2.4.10, which we hope will upgrade in the future. Also, on our internal registry, we have a 3.0.7 available. The maintenance team would prefer the EPEL version.
I'm not quite sure of the differences between the versions. I haven't found a document listing major changes from 2.x to 3.0. Are there major features/ performance improvements/bugfixes in 3.0 that I MUST have?
My first guess is that 2.4.10 would be sufficient enough for my needs.
The most significant change from 2.x to 3.0 is that Redis 3.0 introduces Redis Cluster which is a distributed implementation of Redis.
You can also get change list (bug fix, new features and so on) of other versions from 00-RELEASENOTES file of each version: github link:
We are using Worklight enterprise 6.2 with fix packs and we are planning to upgrade to 6.3 in the next month (beginning of May 2015). However, we see now that IBM is about to release MFP 7.
Can you please clarify to me those queries:
What is the impact on the project which has been developed on version 6.2 to be moved to 6.3 or 7?
What is the recommendation for us in terms of upgrading, should we go immediately to WL7 or to 6.3 first?
We are very close to the production and our concern that the WL7 "might" be unstable or contains issues that we might face in a critical time."Feedback would be appreciated"
MobileFirst Platform Foundation 7.0 is not about to be released - it is already released.
Lots of changes in both 6.3 and 7.0. Read the documentation to see what's changed...
6.3: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.getstart.doc/start/c_release_notes.html
7.0: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.getstart.doc/start/c_release_notes.html
In terms of your project structure, starting 6.3 the adapter thread pool has been removed and you are now in complete control of it. Your adapter XML will be upgraded to the new structure.
In terms of technology, starting 7.0 there is REST support together with a new authentication mechanism - OAuth. Classic authentication is as before and is still there. There are also now Java adapters in addition to JavaScript adapters, and lots more.
7.0 is indeed new, but provides you with a lot of new possibilities.
6.3 is very stable (that is not to say that 7.0 is not stable, but it's also very new).
We cannot decide for you if to upgrade or not, it sounds like you are already considering the right things to consider.
Read about the two releases.
I'd like to get the latest Mono 2.x version.
According to the official Mono release history page it is 2.10.9
According to what appears to be the official archive it is 2.11.4
However the latest modification date in the archive above for a 2.X release actually belongs to 2.10.12
There is no mentioned of the latter two versions in Mono's website (according to Google at least).
Any ideas what's going on?
I found this blog post that suggests 2.11.4 may be an Alpha release (see the comments). Perhaps the same is true for 2.10.12, and the latest stable version was indeed 2.10.9?
A similar questions arises for the latest version of MonoDevelop supporting Mono 2.X.
According to a Xamarin rep in their mailing list it is 2.8.6.5, but the GitHub release history shows 2.9.6, and the following link works: http://download.xamarin.com/monodevelop/Mac/MonoDevelop-2.9.5.dmg.
Is it again a case of an Alpha / Beta release ?
Mono 2.10.12 is the latest stable 2.x release (although 2.10.10, 2.10.11, and 2.10.12 were really just MacOS-specific releases, iirc).
Mono 2.11.x releases were previews for Mono 3.0.
The latest stable 2.x release of MonoDevelop was 2.8.6.5.
MonoDevelop 2.9.x releases were previews for 3.0.
At the time, we used the same version scheme as the Linux kernel for both Mono and MonoDevelop, where an even minor version meant stable and an odd minor version meant development/unstable/preview/alpha/whatever-you-want-to-call-it.
I think Mono still uses the same version scheme, but MonoDevelop no longer does (starting with 5.0). For example, MonoDevelop 5.1 is stable even though the minor version number is odd.