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.
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).
My company has internal components that we deliver via internal NuGet. Now i want to make a Version 5.X of these components which will be breaking a lot from the 4.X versions.
However now if my colleagues browse for updates, the Nuget browser would recommend these new packages.
What i would prefer: If example 4.6 is installed, it would take the highest 4.X version but not 5.0 or above. Making packages for the 5.X path under completely different names would be annoying when the developer choses to upgrade.
Is there a way to mark nuget packages to do something like that? If that's not clear, tell me and i try to clarify.
If your projects are using packages.config, you can use allowedVersions: https://learn.microsoft.com/en-us/nuget/reference/packages-config#schema
There's no way to do this if your project uses PackageReference, but you can upvote (👍) this isse: https://github.com/NuGet/Home/issues/9082
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 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.
I want to compile the latest snapshot version of gedit on OSX as it has a lot of bug fixes and a number of new features, but I'm a little confused about the requirements to compile the sourcecode.
The readme says I need the GTK+-3 libraries, but for the life of me I can't seem to find them. I've gone through the GTK site, but there is only the 2.0 series available. Google doesn't seem to show any results for the 3.0 series either.
Anyone know how/where to get them?
The readme: http://git.gnome.org/browse/gedit/tree/README
GTK 3 has not actually been released yet, it's the current "in-development" version for the upcoming release of Gnome 3. It's still in development and not at all ready for mainstream use.
Still, if you really insist on trying it out, you can get a source tarball from the Gnome FTP server.
GTK+ 3 has been released some time ago (10-Feb-2001):
Sources: http://ftp.gnome.org/pub/GNOME/sources/gtk+/3.0/
Git repo: http://git.gnome.org/browse/gtk+