I was wondering if it is possible to upgrade DS directly from v8.7 to v11.7? Or is it necessary to upgrade to jump version (e.g v9.1) and then upgrade to v11.7.
We have been using the old version for some time now and this has been a lingering question in the group here. We are looking to get the upgraded functionality of 11.7 but are not sure if it will require upgrading to the jump version first.
we have done many such upgrades from 8.x to various higher versions (9 and 11.3 / 11.5). There is no need to do a "intermediary" upgrade, you can go from 8.x to 11.7. As you are aware, anything lower than 11.3 does not offer in place upgrades.
I would suggest to follow a strategy of exporting all the jobs and settings / message handlers etc and then doing a complete clean install. You have the option to do this on a new server, or, backup and install on your current one.
Once done you can then recreate the projects, import the jobs, amend settings and handlers.
Be aware that between versions things like message handlers may change, settings in DSParams may be slightly different. With importing the jobs it is always a good idea to recompile to ensure there are no issues with the latest version.
Things you may notice: more errors / warnings, such as truncation or type conversions, this is due to older versions of DS not reporting this, but in the newer 9.x and 11.x's these are now announced. Null handling is different (there is a legacy option you can add for example) and some other minor changes. It is a good idea to do a full regression test.
Related
I have found myself trying to upgrade Apache Superset from version 0.35 to 0.37 or soon 0.38 as is about to get released.
Our version of superset was heavily modified, from code added to the default superset files to creating new one. We are talking about hundreds of files changed with 1 to 1000+ added lines Given this fact the upgrade fails with a lot of conflicts, something that was expected.
I would like to find a way to make the upgrade to the newest version and keep our modifications as well as making the process easier for future upgrades.
So far (until 0.35) we manage to upgrade to the newest version and solve the conflicts but it became more and more difficult.
The modification were from the front-end jsx files to css to python files.
What I tried and failed:
make a patch file using
diff <0.35 files> <our modified 0.35>
and apply the patch to 0.37 but this did not work as the files are very different between versions and the line numbers changed drastically as well as the folder structure is different in the newer versions.
Is there any way to keep our modification separated and make the process easier for future upgrades?
The more you fork and has the main branch evolves, the harder it gets to upgrade, that is simply to be expected when forking software. Given current high velocity and general pace of change in the Superset code base, and the pre-1.0 status of the software, you can pretty safely assume that any work you do in a fork is likely to be fully revisited every time there's a major upgrade.
The way you prevent that is:
extending only the things that were designed to be extended (plugins, extensions, configuration hooks)
contributing your changes back into the main branch
Many of us have learned that the hard way in our careers. The typical realization is that overtime, the progress in the main branch offer much more value than your customization, and upgrading and applying your customization becomes hard or simply impossible. The usual solution is to look into your customization and identify the really important ones, and try to contribute them back so that they can evolve with the software.
We have a quite big application built on the version 1.8.1. We would like to migrate to version 2.0 or higher. We have a few guestions:
Does exist some step-by-step manual how to do it?
Can we use 2 different versions of ember in the same time? Because of continuous migration...
We would like to avoid overwriting of the whole application...
I would suggest you to update the ember. and keep deprecation warnings open. Then you can try investigating each warning one by one and update the code with the new syntax.
This guide can be very useful : Upgrade to ember 2.x step-by step
Since Ember uses global window scope, it will result in conflicts and its not advisable to use two versions of ember.
It's possible to load different Ember versions based on which route you are on, but I really don't recommend doing that, as you lose all the benefits of having a Single Page App (apps will load again when you transition between them), and you end up doing significantly more work for yourself, with more opportunities to screw up. I'd follow locks' advice and upgrade the app step by step, testing as you go.
I am developing an Django application using the Django 1.3.1 release :
https://code.djangoproject.com/browser/django/tags/releases/1.3.1
I encountered a bug, which has been identified and fixed by the Django team :
https://code.djangoproject.com/ticket/16128
The changeset associated to the bug resolution is located in Django trunk
https://code.djangoproject.com/changeset/17755
My question is : how can I take advantage of the bug resolution, without upgrading to the Django trunk version ?
There a bunch of files attached to the ticket, the latest is :
https://code.djangoproject.com/attachment/ticket/16128/16128.diff
I can see that this file is a standard 'diff' file, which can be processed by the 'patch' utility. I tried to apply it on my django 1.3.1 installation (on a dev machine), but it does not work...The source lines (to be replaced) are not exactly the one expected by the diff file.
To which 'start state' does refer this diff file ? In other words, to which django version can it be applied ?
Is there another way than applying it 'manually' ? Even if I apply it manually, I can see that the patched code call new versions of methods not included in the patch...which means that I have to find out, by reading the code, which other files have to be patched, and patch them...
At this point, I think something like : "waow, it's to complicated, let's wait the next release of Django - 1.5, for this ticket - and find a workaround !". But, in other hand, if the patch system exists, it must be possible to apply this patch to my Django 1.3.1 installation...
Did anyone encountered the same kind of problem ? If so, how did you manage it ?
Thanks in advance for your help
Did you actually try with the Django 1.4 release, which has been issued a few days ago? I am quite sure it is part of it.
Anyways...you can get the official diff at the changeset page that you referenced - at the bottom there is a link to an unified diff. You can download the patch from there and use it to patch(1) your release (beware that should the Django team release a new security release of Django 1.3, you may have to apply it again). However, those diffs are always against the most recent codebase at the time the patch has been committed. For that reason, sometimes you might have a bad luck (like in the case you have described above) and it may not apply cleanly to the previous release. In such case you would have to track down all the changes required to make it work, which may be pretty much work and might be unacceptable. So there are only three options: find your own way to work the bug around, track all the changes required to apply the patch cleanly, or upgrade to the given revision.
We're running an ancient version of fabric (0.9.0). Should I expect any issues if I upgrade to the latest and greatest (1.4?) in a single step?
Some but not many, as the api stayed somewhat consistant. There is a section in the changelog devoted specifically to this question. There also though is now an lcd() for local dir changes to make the local and remote context managers work independent of one another.
Is there a convention for structuring the source code when there are multiple versions of the same web service in the same source code trunk or branch?
Here's our situation.
We version our web services by including the version number in the wsdl URL like this:
url/project/1.0/WebServiceA?wsdl
I'm going to deploy version 1.1 of WebServiceA along with version 1.0 so users of 1.0 don't have to change anything. Version 1.0 and 1.1 of WebServiceA will have their own seperate Java classes.
I want to deploy both versions in the same .war file. (We could adopt a policy of only one version of a web service in the .war and deploy other versions in their own .war. This would result in an increased number of.wars to deploy when we get several versions of several web services. I would prefer to deploy only one .war.)
I'm thinking we should just use a seperate package structure for the various versions:
com.company.dept.ws.WebServiceA (version 1.0)
com.company.dept.ws.v11.WebServiceA (version 1.1)
com.company.dept.ws.WebServiceB (version 1.0)
com.company.dept.ws.v11.WebServiceB (version 1.1)
com.company.dept.ws.v12.WebServiceB (version 1.2)
The Java classes under ws., ws.v11., and ws.v12. would be seperate Java classes.
Can you see any problems down the road with this convention?
If there is a tried-and-true convention for structuring the source code for multiple versions of web service code I'd like to hear about it before I make up my own.
Thanks.
Dean
Since you say you want these versions to all be "in the same source code trunk or branch" I think part of the answer depends on the source control system you're using, and whether or not you ever plan on fixing bugs in older versions.
If you ever want to fix bugs in older versions you'll want the ability to integrate changes forward or backwards between the different versions. For example, suppose you discover a critical security problem that exists in versions 1.0, 1.1 and 1.2. You aren't going to want to fix it 3 times. Most source control systems will let you do that sort of integration between related branches. Some (like Perforce, and I believe also git, and probably a few others) will let you integrate changes between files even within a branch. (in fact, Perforce's concept of a "branch" is just a convenience for recording inter-file integrates)
So you need to think about whether you'll need to make these sorts of multi-version fixes, and if so, can your sorce control system handle intra-branch integrations. If not, then you might be better off using a separate branch for each version.