I am just bumping our 3rd party packages to the latest versions for various vulnerability fixes.
There has been some major changes it seems from awspring 2.4.2 -> 3.0.0.M*, notably quite a few classes have been removed. One of them being ResourceIdResolver.
See - https://github.com/awspring/spring-cloud-aws/pull/252/files
I can't find any release docs advising of the above class removal and no help as to how to refactor your code to get around the fact this class is no more.
I notice that package io.awspring.cloud.messaging is still at 2.4.2 and class QueueMessagingTemplate is referencing io.awspring.cloud.core.env.ResourceIdResolver (which no longer exists in io.awspring.cloud.core 3.0.0.M2.
Is there some compatibility issue here?
Many thanks
Related
I have a utility service x which is in maven repo and is used by some of my other services. We normally update the minor version of the service x when we make small changes and we are currently on version 1.0.15.
No I am making another change and I was thinking whether I should update version to 1.0.16 or I should update the version like 1.1.0.
If anyone can provide an explanation on how this should be done in general, that would I am sure help other developers as well as me. Please let me know if you need further information.
Different projects follow different standards on this, so follow what the repository has done to date.
A well-regarded standard for this is called Semantic Versioning (https://semver.org/). If you are starting a new project or there isn't a standard already in place, I would recommend using this.
Semantic Versions are in the format: MAJOR.MINOR.PATCH.
If you have fixed a bug: increase the patch version
If you have introduced new functionality in a non-breaking way: increase the minor version (and reset patch to 0)
If you have introduced breaking changes: increase the major version (and reset the patch and minor version to 0).
If you are unsure whether your change is a breaking change or not - consider your package (or API) from its consumers' perspectives. If their code has to change as a result of your change then it's a breaking change.
I have an question regarding updates to the framework of a Laravel application.
Normally I run the composer update command to update all of its dependencies. For the laravel framework the package laravel/framework is used.
But they made some changes in this package which require you to make changes in the core application (not in composer). The core application is the package laravel/laravel.
For example, in this commit they have made a function called confirmPassword() which refers to a file ConfirmPasswordController.php in the package laravel/laravel.
But this file didn't exists on my application because my application is not up-to-date.
My question
How do i keep my core application up to date?
Errors
See a typical example of updating the dependencies but not the application here.
First of all... This is not an easy question and IMO there are MANY possible scenarios... Depending on the code you developed, the packages you're using, the version you want to use, and so on...
Anyway This is what I would do in this situation:
Let's say for example I want to upgrade from version X to version Z where Z is two major / minor releases ahead of X
Step 1
Follow the next steps for one major / minor realease at time. Once I've tried to upgrade an application from Laravel 5.4 to 5.6 and it was completely broken. So I decided to upgrade to 5.5 and test the everything was working and, in case, block at that release. Luckily when I've upgraded from 5.5 to 5.6 (after code fix) I've managed to make everything work as it should.
Step 2
Upgrade the core framework and the plugins, check for errors during the upgrade and ofc, check the official documentation for any kind of compatibility problem
Step 3
Laravel has it's own upgrade guide that should be followed step by step. A good chunk of errors can be solved simply following that guide. There may be some plugins that doesn't provide it but usually the problems are releated to new features... It's hard that a method, class or trait has completely changed from one version to another.
Step 4
This step can be omitted, but from the example you've provided maybe it's better to add it. When there is a new feature that requires a specific class or trait or whatsoever, the simplest way to check if the error is thrown because of a file missing (and that is part of the "boilerplate") or has a different nature, is to create an empty project with that specific version and make a comparison with the "default" files.
For example, if you made no changes to the LoginController, checking if the new version has any kind of updates, may be the solution.
You can do this manually, following the upgrade guide for the version you're upgrading from/to, for example this one.
Alternatively, Laravel Shift is a paid but fairly inexpensive tool that will do it for you automatically. Since it's making changes to your project, you should carefully review everything it's done.
I am working on a CakePHP 3.0 project which I want to update to 3.1-RC1. When I try do so I get an error:
Problem 1
- akkaweb/cakephp-facebook dev-master requires cakephp/cakephp 3.0.x-dev -> satisfiable by cakephp/cakephp[3.0.x-dev].
Now this plugin in question hasn't been updated in 6 months and I suspect it might work OK in CakePHP 3.1, so I would like to try it out.
How do I tell Composer to ignore this particular version incompatibility and proceed to update my CakePHP package?
I am aware of version aliases, but I only want the exception to be for the plugin in question, and not for everything else.
You should be frightened when you want to use a software that isn't maintained, hasn't released any tagged versions, and depends on developer branch versions of other important software. I wouldn't use this package at all. It will harm you in the long term, even if you made Composer install it.
If the current author does not respond to your contact attempts, you should be able to fork the project (in compliance with the license it gave you) and start maintaining the package by fixing the problems you have. Because that's what you'd have to do anyways when using unmaintained software. It will allow you to use this package in a much cleaner way, instead of coming up with a dirty Composer hack to make it install.
I have an extension package on our corporate nuget server for Asp.Net MVC 3 - let's say the package ID is currently Acme.Mvc and it's version is 2.x.
I've now branched that project and going to put a pre-release version of the same package targetted at MVC 4 Beta. Now, logically this is now version 3.x of the library; however, as soon as I release it (once it's no longer pre-release), the 2.x will no longer appear in VS' UI; which will potentially lead to other developers adding it to their MVC 3 projects; and deny them easy access to any future upgrades to the older v2.x library without using the console).
In a couple of other cases, I've changed the package id to include a version i.e. Acme.Mvc.3 so the new and old can sit side by side. Only problem with that is that it's then possible for someone to try and include both! There's also the slightly pedantic issue that to call that v3.x is not necessarily correct; because it's a new package.
Also, I really need to be able to maintain both streams. I can rely on Binding Redirects in MVC 4 sites that still reference the version of the library that targets MVC 3; since none of my extensions rely on stuff that's gone.
When I look at the public nuget feeds; I rarely ever see this practise of sticking a major version in the package ID, but is there really any alternative?
There are many existing packages that uses the MVC version as part of their naming convention to differentiate between supported versions :
WindowsAzure.WebRole.MVC3
Unity.Mvc3
Spark.Web.Mvc2
Spark.Web.Mvc3
...
"Only problem with that is that it's then possible for someone to try and include both!"
I wouldn't bother trying to block this case, it would seem obvious by the name of the package that both are not meant to be side-by-side.
I have an existing ASP.NET MVC3 site that has been built with Sharp Architecture 1.9.6 and I'd like to upgrade to 2.0.4.
I've used NuGet to: Update-Package sharp-architecture. Obviously there are a number of compile issues...so I've been trying to update the references using the version history as a rough guide.
Unfortunately, it hasn't helped all that much since namespaces like SharpArch.Infrastructure seem to have disappeared somewhere between 2.0.0 --> 2.0.4 which is odd because I thought they used Semantic Versioning... but anyway...
I've been searching the interwebs for a guide on how to upgrade and I haven't come across anything helpful. Even reading through the sharp architecture blog hasn't helped me with this problem...
So does anyone know if there is a guide for how to upgrade to version 2.0.x? Surely it must be possible. Or is one expected to start a new site using Templify?