What version of the rspec-rails gem is still compatible with Rails 2.3 branch (2.3.14 specifically)? I've tried 2.1.0, but that one's also for Rails >= 3.0. Any other dependencies or version limitations that I should be aware of?
Thanks.
Version 1.3.4 is the latest supported version for Rails 2.x.
http://rubygems.org/gems/rspec-rails/versions/1.3.4
Related
Assuming I'm already using the NuGet Package
Microsoft.AspNetCore.Components 5.0.3
Can I upgrade it to 5.0.5 without having the 5.0.5 runtime installed (dotnet --list-runtimes)?
If I look at the dependencies in Nuget it just states:
net5.0 (no specific sdk, nor runtime)
-> Microsoft.AspNetCore.Components.Analyzers (>= 5.0.5)
-> Microsoft.AspNetCore.Authorization (>= 5.0.5)
Is there a specific reason to upgrade to 5.0.5 from 5.0.3? If its because you need something specific added in 5.0.5, then, while it might work, chances are it wont, as Andy says
I have a dotnet core 2.1 lts docker image and I need to have a timestamp in the log. The Microsoft.Extensions.Logging preview for dotnet core 3.0 has this feature. Of course this package will not have long term support.
Can I combine a nuget package, which share the version of dotnet core, with a lower version of the dotnet core framework or does that result into in unsupported setup?
You didn't specify what your applications uses, so I need to write a somewhat generic answer.
The package Microsoft.Extensions.Logging targets netstandard 2.0, which means it will work on dotnet core 2.1
This issue you will have, is that it will force the dependencies it uses to upgrade too:
Microsoft.Extensions.Configuration.Binder (>= 3.0.0-preview4.19216.2)
Microsoft.Extensions.DependencyInjection (>= 3.0.0-preview4.19216.2)
Microsoft.Extensions.Logging.Abstractions (>= 3.0.0-preview4.19216.2)
Microsoft.Extensions.Options (>= 3.0.0-preview4.19216.2)
And those have dependencies too... in the end it might upgrade quite a lot of your project dependencies with packages which are in preview. (thus not supported)
I would not advice you to do this, but in the end it simply depends on what functionality you are using in your application. If only your code depends on the Microsoft.Extensions.Logging functionality you should be okay, although currently not supported. As soon as you use other packages which use one of the upgrade Microsoft.Extensions package the major version change should tell you that this might cause issues.
When I deploy my .net core 2.1.0 project, I get the following error:
-----> Installing dotnet-framework 2.0.3
**ERROR** DEPENDENCY MISSING IN MANIFEST:
Version 2.0.3 of dependency dotnet-framework is not supported by this buildpack.
The versions of dotnet-framework supported in this buildpack are:
- 1.0.5
- 1.0.10
- 1.0.11
- 1.1.2
- 1.1.7
- 1.1.8
- 2.0.0
- 2.0.7
- 2.1.0
All solutions in my project is targeting the .net core framework 2.1.0, so I don't understand why this is.
I have dependencies in my project, and some of the them, like NETStandard.Library and Microsoft.NETCore.DotNetAppHost, are version 2.0.3, but does that really matter? (Also I don't think a version higher than 2.0.3 exist of NetStandard.Library.)
The project runs fine on my local machine, and ran fine on the host before we upgraded the buildpack and target .net framework, as well as various dependencies through NuGet.
Here is the full log:
https://1drv.ms/t/s!Ar81AKlFywcPhapTJdjZEnrcGrZS4A
You can try to pin the RuntimeFrameworkVersion to a specific one:
<RuntimeFrameworkVersion>2.0.7</RuntimeFrameworkVersion>
started with 4.0.1
in buildout.cfg
extends =
base.cfg
# versions.cfg
# http://dist.plone.org/release/4.1-latest/versions.cfg
http://dist.plone.org/release/4.2-latest/versions.cfg
4.0 -> 4.1 went fine
4.1 -> 4.2 gives zc.buildout version error I haven't figured out
bin/buildout
Error: There is a version conflict.
We already have: zc.buildout 1.4.4
but zc.recipe.egg 1.3.2 requires 'zc.buildout>=1.5.0'
http://buildoutcoredev.readthedocs.org/en/latest/issues.html
seems to suggest remedies:
"To fix, you have a couple options. First, you can force buildout to run with the version you already have installed by invoking the version tag. This tells your [Plone] bootstrap.py file to play nicely with the version that you already have installed."
In my case that would be
python bootstrap.py --version=1.4.4
However this doesn't help, same error as before,
the other suggestion, deleting the zc.buildout egg,
fails hard.
Suggestions?
Thanks,
Kent
That way will not work as zc.recipe.egg 1.3.2 requires zc.buildout 1.5+.
You can try to downgrade zc.buildout.egg to an older version (a version that do not require so recent zc.buildout, give it a try) or upgrade zc.buildout.
I suggest you to upgrade your zc.buildout, pinning a modern version:
[buildout]
...
[versions]
...
zc.buildout = 2.4.4
I'm planning a new build system for our project running on Centos 5.4. I intend to use SCons. I noticed the latest stable SCons version is 2.0.1 while Centos 5.4 comes with 1.2.
I'm new to SCons so I'd like to understand more about the features/stability ratio between the versions.
Would you recommend installing and using the latest version or sticking to what comes from my OS repository?
Since 1.2 the changes have been bug fixes and documentation improvements. There haven't been any new features.
The 2.x version of SCons drops support for Python versions older than 2.4, updating some of the internal code to use newer idioms but without affecting any user visible APIs. That's the reason for the major version number change. If CentOS comes with a recent version of python then this won't affect you either way.
There have been a lot of fixes for newer versions of the various Microsoft compiler versions, but this won't affect a CentOS install.
The bug fixes since SCons 1.2.0 also solve problems in the Fortran, TeX and LaTeX builders. If you make use of Fortran or LaTeX then it would probably be worth upgrading. Otherwise I think you would be hard pushed to spot any day-to-day difference between 1.2.0 and 2.0.1.