TiDB provides so many different versions and the documentation also mentions different versions for users to install. How to avoid choosing the wrong TiDB version and TiDB-Ansible version? What's the difference between various TiDB master versions?
The TiDB community is highly active. After the 1.0 GA release, the engineers have been keeping optimizing and fixing bugs. Therefore, the TiDB version is updated quite fast. If you want to keep informed of the latest version, see TiDB Weekly update.
If you have questions regarding which version to use, email to info#pingcap.com for more information or file an issue.
It is recommended to deploy the TiDB cluster using the latest version of TiDB-Ansible, which will also be updated along with the TiDB version. TiDB has a unified management of the version number after the 1.0 GA release. You can view the version number using the following two methods:
select tidb_version()
tidb-server -V
Related
wanted to get the opinion of the people for this one. Currently I am working on setting retention policies inside Artifacts in DevOps, I want to get some clarification on how exactly that works. For example: Lets say I set my Max number of version per package to 10 and my Days to keep recently downloaded packages 14. I currently have these versions for my builds:
3.0.1.1.4
3.0.2.1.2 - 3.0.2.1.8
3.1.2.0.1 - 3.1.2.0.4
Is it possible with azure retention policies to keep versions 3.0.1, even if its not the latest version of my build? I assume it will just save the 10 latest versions of the build which would be 3.0.2.1.2 - 3.1.2.0.4. Let me know if I am assuming correctly. Assume no packages have been downloaded for this scenario.
Another alternative I was thinking about using is maybe Artifactory, who to me seems fairly similar? Not really too sure about it. I want to know which one is best for retention policies overall to reduce cost. Any information help, I know its not the clear thing in the world so if you have any questions just let me know.
Preamble
My org is low-risk so we're planning to stick to LTS releases (.NET Core 3.1 at the time of this post.) The Nuget Package Manager Updates list, however, currently offers non-LTS updates (namely to .NET 5.0.)
Question
Is there a way to configure Visual Studio in a way to show LTS updates only? Alternatively, is there any other way I can achieve the same desired result?
(This question is actually almost a copy of Lion's original, but I'm hoping that improvements on api.nuget.org or in the way Visual Studio handles API results may result in a viable answer.)
Your question is a real good question. And many community members want this feature on PackageReference for net core projects.
In fact, what you want is not supported on PackageReference so far. And net framework projects with packages.config nuget management format can realize it. See this official document.
Under packages.config, you can use allowedVersions node for nuget packages on packages.config file, such as [3.1.0, 5.0.0). It means 3.1.0 <= current version < 5.0.0. You can only update the nuget package under that range on the Nuget Package Manager UI.
It is quite useful feature but Microsoft has not added this feature for the new-sdk project with PackageReferece. Therefore, many community members has raised this issue on github which is still in processing.
And the Team has planned to fix the problem on December 20. So I suggest you could follow that github link and add any comments to describe your issue to raise more attention from Microsoft' team. All of them will help solve the problem as soon as possible.
I've checked my installed programs in windows 7 machine. In it there are several copies of Microsoft Visual C++ were installed. I know they provide support files for various programs and softwares I've installed in past.
But If I uninstall the older one, will the associated software or games misbehave??? or should I keep them installed?
And if I have to keep them all installed for the sake of their associated softwares, How can I find out some useless copies of this MSVC++ if their main programs were uninstalled already????
Thanks in advance :)
You did not mention the games you intend to make sure will work. Even if you did, I doubt anyone here is developing all the games, so an exact answer is unlikely to be given here.
However, new versions of any software should be as much compatible with older versions as possible and you should keep that in mind when you see all the versions, so you should be able to keep only the latest installation.
However, the way to find out is to perform the following algorithm
for each installation ordered by version except the last
uninstall
test all the games sequentially
if any tests failed, then reinstall the given version
end for each
Don't know exactly but the latest version of visual c++ will be good enough for all other programs
I'm setting up reproducible build environments for our product using Vagrant and VirtualBox. We are targeting RHEL7, Oracle7 and Ubuntu 14. I have read a few RPM build guides but one thing is not clear to me. Using RHEL6 as an example, say I build an rpm on RHEL 6.4 but want to ensure compatibility with 6.0 and up. Will the generated RPM be compatible with the whole RHEL 6 series or do I need to build on 6.0 to ensure that?
Basically I'm trying to decide if I should have Vagrant update the systems to the latest minor release and packages in my rpm build environments.
Generally yes, as long as you're only dependent on public interfaces. Determining what a public interface is, isn't all that easy though.
From Red Hat Enterprise Linux: Application Compatibility GUIDE
During the life cycle of a major release, Red Hat makes commercially
reasonable efforts to maintain binary compatibility for the core
runtime environment across all minor releases and errata advisories.
That's the best guarantee you'll get it seems. Edit: See also Red Hat Enterprise Linux Application Compatibility Policies
During RHEL 5.x and 6.x, we've built many projects whose binaries were run on older minor releases,
I've not seen any problems. (Although the binary interface for these applications is minimal, limited to libc/libstdc++ and 3-4 other libraries - and a few python programs)
(As a side note if you're building kernel modules, the kernel provides no ABI guarantee and may change between minor releases.)
I'd always operated under the assumption that the compatibility guarantee was from anywhere in the series to anywhere in the series but I've seen at least one instance where that was broken (I don't know if that was accidental or not though).
So, for safety, I would probably suggest using the oldest revision of the series that you officially want to support.
I rolled out JMock at our company, and many folks are using it with success. The version we are using is the latest stable release, which is 2.5.1. That was released in August 2008. Since then, two release candidates came out, 2.6.0RC1 and RC2 in 12/08 and 9/10, respectively. That seems like a long time for a release to be a "candidate." I'd like to update to 2.6.0, but my company is hesitant to use a product that is not a "stable" release. I share their concerns.
I have two questions about this. First, for anyone using the 2.6.0 RC1 or RC2 releases, have you found any evidence of instability in these versions?
Second, and this is more for the folks who created the tool, why is 2.6.0 considered still a release candidate and are there plans to release a "stable" 2.6.0?
Thanks!
Ken
2.6.0.RC2 seems to be perfectly stable. I'd have no issues with using that in anger.
I understand there are plans to push 2.6.0 to a full release, and that it's just a matter of free time to do it...
We're trying to get a release out but are short of maven help