Suppose one person is using Bazaar 2.3 on Linux, and another is using Bazaar 2.5 on Windows. Are there problems that may result from pushing, pulling, or merging between repositories on the different releases and operating systems? Or is it designed to interoperate seamlessly across the different release versions and OS? What about older and newer versions, say 2.6 and 2.2 -- will the compatibility similarly hold?
Apparently versions 2.x are all compatible with each other.
Related
For context, I am researching upgrades into our OpenCL code at work as we are quite far behind current spec. The team I work in develops on all three of the major OSes and as far as I can tell Apple doesn't support past OpenCL 1.2 on any of their machines instead prompting you to learn and use Metal performance shaders.
I would like to update our code base to C++ for OpenCL which is based on OpenCL 2.0 or 3.0 depending on which version you use. C++ for OpenCL is fine on Windows and Linux as they have GPU drivers which support up to and past the 2.0 requirement, but Mac might have a problem with it without official support in the drivers. So I had the idea that if we could cross compile the CL kernels to Metal for the Mac users they would be able to run a Metal version of the code locally.
Has anyone got any solutions to this problem.
I have been reading a while on the subject and I came across an article which left me a little bit lost on software versioning/releases.
If you follow it you will see it's just a list of all Symfony releases with their respective dates. What prompted me to ask this question was the fact that I could not get why/how, for example:
Symfony 2.8.37 released | April 2, 2018
while
Symfony 4.0.6 released | March 5, 2018
Symfony is just the example, my question applies to software versioning in general looking for an explanation to the above.
I am (am I?) positive that 2.8.37 is older than 4.0.6 so this most certainly has nothing to do with me comparing them wrong, surely there is a fundamental aspect about the versions release process I'm unaware of.
Finally, just to be sure, if I were to compare two versions, how would I go about it, I don't need a computer-language-specific-solution, just an algorithm in general to compare two given versions like you could do even using paper and pencil (I know, what a heathen).
Typically, 2.8.38 would be a security or other patch to 2.8.37; and 4.0.6 is a patch to 4.0.5, where 4.0 is a newer, more powerful base version that requires a different license or runs only under Windows 10 or some other reason why some people would like to stay on the old version.
The patch to the current version would be published faster, and then the team adds the important security patch to the older versions.
Symfony has very good support for old versions of their framework. Basically Symfony 2 was released and went through various version changes similar to 2.1 -> 2.2 etc. All the while maintaining compatibility with previous Symfony 2 projects.
Further down the road Symfony 3 was released, and while a Symfony 2 project could be updated to a Symfony 3 project it involves some work and there can be project breaking coding changes required. Then Symfony 3 progress 3.1 -> 3.2 etc.
Just because Symfony 3 is out and available doesn't mean that all work or bug fixes are done on Symfony 2. So there will still be releases of Symfony 2, in addition to releases of Symfony 3. Here is a visual view from the Symfony Page to show the version overlaps.
This is common with most software, for example Microsoft Windows 10 is the current version but Microsoft still provides patches for Windows 7.
I need to implement a truly working platform version filter targeted to version 1.2 for my open-source project:
https://github.com/tugrul512bit/Cekirdekler
I don't have 150$ to buy an OpenCL2.0 capable graphics card for now so I'm working on a pure-1.2 version system and not sure about other (new)systems.
Question: How does a list of platforms looks like when there are only opencl 2.0 capable gpus and both 1.2(max) and 2.0(max) capable gpus exist in same system?
Lets assume I'm using this
clGetPlatformIDs()
to get a list. Should I suppose it gives only single version platforms per device or,
For example, a GTX-Titan XP(opencl 2.0 capable?) can list two platforms:
OpenCL 1.2
OpenCL 2.0
separately for same device? Or it just gives 2.0 version?
What about a GTX-TitanXP and a GT-640?
OpenCL 1.2 (TitanXP + GT-640)
OpenCL 2.0 (TitanXP)
or
OpenCL 2.0 (TitanXP)
OpenCL 1.2 (GT-640)
which one happens?
Can this change with drivers?
What about OpenCL version 2.3 GPUs? Do they seem as 2.0 in OpenCL API or correctly give 3 as minor version?
If anyone could share his/hers experience, I appreciate.
For now, project can take 1.2 or 2.0 versions (Intel drivers I installed have an experimental version 2.1 with bugs so I filter-out with minor version checking, I'm not sure if Nvidia or Amd can do similar or opposite things in OpenCL-2.x capable cards). I can also filter for platform names "experimental"/"beta" to elliminate such platforms but I'm not sure if there are multiple versions for same GPUs.
I assume 2.0 devices have backwards compatilibity for 1.2 but do I need anything extra to enable 1.2 spec? For now I'm not doing anything extra for 1.2 devices. Maybe 2.0 needs some?
Each platform returns its own version number independently of the others. You can have a mix, for example a GPU at 1.2 and a CPU driver at 2.0.
If you make only OpenCL 1.2 API calls you can use either. If you make OpenCL 2.0 API calls you can only use 2.0 or higher platforms.
Likewise, devices within a platform can return their own version numbers, although I don't think they can be larger than their parent platform number. An example of this is an older GPU, which might only be OpenCL 1.1 even though the platform is 1.2.
Separate from this is the version of OpenCL kernel language each device supports. For backwards compatibility if you don't pass compile options you are getting OpenCL C 1.x. If you are on a 2.x device you can pass an option string when compiling your kernel to get new language features.
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 haven't read very much about MPI's implementation yet, but I was asked to setup a third party software statically linked against version 1.4.1pl of MPICH2 with an environment that runs the MPICH2 runtime with version 1.2.1.
Should I expect problems?
It will probably work, but it's not ideal. There are certainly bugs in 1.2.1 that have long been fixed. And since we don't usually test mixed version installations, bugs are more likely to occur in mixed version installations.
If you have odd configurations of the 1.2.1 environment (non-default process managers or PMI libraries), then the odds of a problem increase substantially.