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.
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.
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.
We experienced strange behaviour. Especially under chrome, some items are missing. Anyone ?
Which version are you using? You should always pin the version you use, which means that once it's published, it will never change.
The code is open source, you can check yourself from the github repository and there are other more appropriate channels than Stack Overflow, IMO:
The Django weblog, where a post is published each time there is a new release.
The Django users mailing list/google group is another place where you can keep up to date.
PyPI gives you the release history.
Finally, with any open source software, don't be afraid of digging into the source code and see what has changed. Github has a great way of comparing between 2 tags, for instance for the latest 2 1.11.x relases: https://github.com/django/django/compare/1.11.16...1.11.17
There was 2 new bugfix relases published on each 2.1.x and 1.11.x branches yesterday, so if your dependencies aren't pinned, you might have auto-updated, but without further details it's hard to tell you more.
I've seen Pinax in the past and I'd like to use it today. It's on version 0.7. I wonder know if it's still in development.
It is very alive, as you can see in its GitHub repository
It's very much under active development. Check out http://groups.google.com/group/pinax-users for the latest info.
An important note:
Much of Pinax is Django-apps which are developed separately from pinax and are brought in via version control systems (subversion, mercurial, git, etc)
So even if the pinax project maintainers were to go on a 6 month hiatus (though they are very unlikely to), the platform would continue to be updated and receive bug fixes
I'm updating a 0.5.1 complete_project to 0.7beta3 + virtualenv + pip + fabric.
I have converted my project into multiple stand-alone applications and I have everything being pulled down by pip from a requirements.txt file.
I am now moving the code over and so far can get the Welcome page and perform a log-in, but then it breaks, due, it appears, to the introduction of Group support and the refactoring of Tribes into Tribes and Topics.
Has anyone successfully made this move? If you did, how did you handle migrating your data? What should I be looking out for? Anyone have a checklist or list of steps? What other exciting challenges do I have to look forward to?
The short answer as far as I'm aware (and I've been following Pinax development for some time now) is that there is no straightforward path to upgrade the project from 0.5.1 to 0.7beta3. I'm not sure how familiar you are with the code, but this is the process I would use based on my limited experience:
Start by using the social_project/ that ships with the latest version of Pinax. Copy into it any changes you made to the settings.py file as well as any custom apps you have.
The templates and media have moved to folders outside of the projects, but if you customized any of them (I'm sure you did) take the custom ones and drop them into the template folders in your project to override those in the default theme folders. You should compare them to those in the theme folders to see what changes may need to be made to keep up with changes in the apps.
The next step would be to do the same thing with urls.py copying any customizations over the one provided by the project.
Try getting it running at this point with a fresh DB. Hopefully any errors will point you in the right direction to stuff that you might have missed or not known about.
Once you gotten it running most of the DB tables should be the same (I believe) except as you mentioned the Tribes stuff. Migrating the data, though, is still beyond what I've had to deal with.
Disclaimer: I've been following development but never had to perform an upgrade quite this big. Good luck and (obviously) back up your work and data before trying to port it all over.
See the documentation and code ( http://github.com/pinax/pinax/tree/master ) for more details. The code is a convenient (though tedious) way to watch the evolution between 0.5.1 and 0.7beta3, for what that's worth.