I understand that NuGet packages update process is not automatic for a good reason (a new version could break your code or cause unforeseen problems), but then it transfers the responsibility of updating all packages to the developers themselves. When exactly should we be updating NuGet packages for a given project? Are there some guidelines regarding this process?
In our current project, this is more or less arbitrary: I update packages whenever I remember to check for updates, and preferably at the start of a sprint so that, if there are problems with the newer versions, we are able to fix them or rollback to the previous versions of the offending package. Most of the time, I'm the only developer that worries about this stuff, but I feel it is valuable to always be as up to date as possible because of performance reasons and new features that can make our work easier.
Well, you should update whenever you are able to cope with it.
So you need to think carefully about the regression updating the packages could cause to your application if already in production, or the extra tests you are going to need to carry on in order to verify everything seems to be working as expected.
Normally updating to newer minor versions shouldn't cause much problems, but you always have the risk of it. Looking at the newer version release notes could prepare you to what to expect of the update.
In summary, update when you can cope with it, and you are ok with any shouting from your testers if suddenly the system regress without them even knowing it was coming :)
Few tips to decide package update strategy:
Don't run production application on a deprecated (not-maintained) package version. Upgrade to a maintained version at bare minimum if unable to upgrade to latest.
Don't run production application on a pre-release (not-stable) package version. Upgrade to a stable maintained version.
While upgrading by a major version, read publisher's release notes to understand the implication backward-compatibility from application context. This will help put a better estimate on development and testing efforts.
Related
I am new to moodle and I need to do an upgrade. I have several questions first:
I have to upgrade from 3.4 to 3.5 and then to 3.9. Would I have to install all custom/aditional modules to 3.5 or can I do it just on 3.9.
This might be a dumb question, but I want to make sure I don't give anything for granted. In other to know which are custom/aditional modules I just have to go to the plugins view in administration and just copy the plugins that are on the section aditional plugins, right?
Thanks in advance
In general, you can get away with not installing all the custom plugins in 3.5. It is, in theory, possible that a 3rd-party plugin would choose to clean up their older upgrade steps, in the same way that core code does (which is why you can't jump direct from 3.4 to 3.9). I can't remember of any occasion where I've been caught out by a plugin doing that (and I've prepared hundreds of upgrades for different customers over the years). Note: you will see messages about plugins 'missing from disk' during the 3.5 upgrade step, but those should be fixed when you add the plugins back to the 3.9 code.
The list of additional plugins contains all of the plugins that are not part of the core Moodle code. It won't tell you about any custom changes that have been made to core Moodle files, but if you have simply been installing plugins and not messing around with core files (which is true in almost all cases), then you should be able to rely on the list.
Hopefully it goes without saying that you should always take a full database and moodledata backup before you start the upgrade, just in case there are problems (but, in my experience, they are fairly rare with normal upgrades).
now that they release v0.5.0 the question is how can I upgrade from 0.4.6 to 0.5.0 without loosing all my packages? is there even a way. Or if there is no easy way, how have people done it? What is the best way to do it?
Other question is, is it worth it or do I need to upgrade? What are the benefits or why I should not upgrade (yet)? Is there problems with Atom and other packages?
Yes there is quest same question already, but it is for older version and I thought if something has changed on upgrading.
You can go into your .julia/v0.4 folder and copy the REQUIRE file to the v0.5 folder. Then when you Pkg.update() your packages should automatically install.
There are very many upgrades (broadcast syntax, arraypoclypse, string changes, etc.), and many packages may stop supporting v0.4 for this reason. I would recommend you start upgrading soon. Juno has already released its v0.5 version, so when you update it should be compatible.
I'm currently using EF7 - beta4 and would like to use beta6. I know I'm playing with fire by using nightlies, but has anyone else done this and have been able to build after upgrading?
I've added the nightly nuget repository: https://www.myget.org/F/aspnetvnext/api/v2/ but when ever I upgrade a package it totally trashes all of .net in both DNX 4.5.1 and DNX Core 5. Now I'm not crazy enough to do this in a working project, so I'm testing this out in new empty mvc project and when I attempt to build I get in excess of 2000 errors from everything.
Has anyone else attempted this and if so how does one get around all the errors?
The nightly builds are highly unstable. Here are some pointers for working on the bleeding edge of ASP.NET.
Reset all packages. Sometimes nightly builds break other packages. Delete project.lock.json and delete all packages (~/.dnx/packages/). Reinstalling may help you get a coherent set.
Upgrade DNX. dnvm upgrade -u. This installs the latest, unstable version of DNX.
Submit issues. If it's breaking for you, it may not just be you.
Pay attention to the ASP.NET on GitHub. Nightly builds are usually only a few days behind the latest changes to the dev branch. We are working fast, and breaking things.
If stability is important, stick to the Nuget.org betas. Beta5 was just released yesterday, and has been more thoroughly vetted for stability.
Watch the Announcements repository to receive a heads-up on breaking changes.
I use Github for managing my code.
Is it bad style if I would delete a release which has a big and clear error and people will have trouble with it?
The thing here is that on my machine I had no troubles, but if you are on MAC the plugin will bomb the application.
What do you do in these cases?
Just release a new version increasing the patch level, this is called semantic versioning.
If your version number is 1.0.0, release a new one with number 1.0.1, and explain which bugs were fixed in your changelog file.
HI, In mongodb site there are two setups available in production release.So what is nightly whats the difference between 1.6.5 and nightly?
I would expect the 1.6.5 one is the official build release for that version. The nightly build is most likely the nightly build for that branch of development.
If there was a bug (security issue, whatever) which was discovered in 1.6.5, it would likely be fixed (over however many days it might take), at which point the fix (which may or may not be feature-complete) would appear in the nightlies, but not yet in the final release above it. When they were happy it was ready for release, there would be a new release from the 1.6 branch (most likely 1.6.6) and the cycle would continue until the 1.8 branch (which is currently 1.7) replaced 1.6 as the stable GA branch. MongoDB's version numbering strategy is explained here.
I hope that makes sense, and I believe that would most likely be what happens. Of course, if anyone is involved in MongoDB's development and wishes to correct me, feel free. :)