I ask this question in the hope of collecting all the incompatible changes/bugfixes in Flex 3.*, of which the maintainer of a Flex 2.0.1 application needs to be aware before upgrading. I'm thinking of issues of the following nature:
Bugs in 2.0.1 that had had some workaround, and have been fixed in 3.*, rendering the workaround not only useless but also erroneous.
Bugs introduced in 3.* that worked in 2.0.1, needing new workarounds.
Features that behave slightly differently (events, attributes, etc.).
Incompatible internal changes, that should not effect the progammer, unless they meddled a bit with the internal objects of the framework, like I did. :-)
Anything not fitting in any of these categories.
(I found several such issues, when I last tried this some time ago. Unfortunately I didn't take notes, and I forgot them since then, but I will update this post when I figure them out again. I reported one issue on the Adobe bug tracking site, it was unfortunately deferred.)
It would also be interesting to read about the advantages/drawbacks of such an upgrade. Are there any showstoppers?
here are some links that may help in your endeavors:
http://blogs.adobe.com/flexdoc/2008/02/migrating_from_flex_2_to_flex.html
http://blog.comtaste.com/2007/06/migrate_from_flex_2_to_flex_3.html
http://butterfliesandbugs.wordpress.com/category/flex-migration/
http://butterfliesandbugs.wordpress.com/2008/03/04/understanding-flex-3-migration-issues-part-i/
http://butterfliesandbugs.wordpress.com/2008/03/06/understanding-flex-3-migration-issues-part-ii/
http://butterfliesandbugs.wordpress.com/2008/03/16/understanding-flex-3-migration-issues-part-iii/
For the record, most of the migration problems from Flex 2 to 3 are minor, especially when compared to the problems of migrating from Flex 1.x to 2. I upgraded several applications with no problems at all. That being said, the above links should help note most of the problems you might run into.
Related
I have a lot of UI Automation JavaScript code which is no longer useable since support was dropped in Xcode.
I'm looking for any means possible to try an reuse as much of the code as possible.
I just wondered if there's is any sort of migration path or hack to make it useable ?
I haven't seen anything so far.
Well, I've waited enough for iOS QA Automation Engineers to share their professional view on the matter, but since none showed up, I'll give it a go.
First off, you are not alone. UI Automation support has been dropped since XCode 8 and a lot of other people had the same problem.
The main takeaway from all the materials I've read online is this:
The only version of Appium that will work with xcode 8 is 1.6.0. You can download the beta now. Instruments/UIAutomation have been removed and only Appium's XCUITest support will work moving forward.
Moving forward, the best document to get you started with your test case migration, or at least give you some helping tips is this one: Migrating your iOS tests from UIAutomation (iOS 9.3 and below) to XCUITest (iOS 9.3 and up) [UPDATED LINK].
The article covers some pretty hot topics considering your situation:
Element class name schema;
Page source;
Locator strategies (with xpath emphasis);
Dependencies, API differences, etc.
You will have to start using appium-xcuitest-driver instead of appium-ios-driver.
Installation & Setup:
Apart from the relevant info that you'll find on appium-xcuitest-driver's official GitHub repo, the bread and butter is here: Setting up iOS Real Devices Tests with XCUITest.
Getting started with a new framework/set of libs, or migrating from one tool-suite to another is always hard, but from past experiences, once you have a working setup and build your first test case, everything else will go smoothly afterwards.
Finally, I could pro-long the response, but the official documentation will always do a better job.
Hope is helps in any way, shape, or form. Cheers!
Are there breaking changes in Moment from version 2.1.0 to 2.13.0?
I just inherited a code base that is using the older version and want to know if there will be problems upgrading to 2.13 from 2.1. Unfortunately there are no JavaScript unit tests for our web app.
I can say that in general, moment follows SemVer, so there are no breaking API changes.
However you may find some behavioral changes, as various bugs have been fixed over the years. Some consider it a "breaking change" when they depended on a particular bug being exhibited and later the bug was fixed, or when a function was improved to be more semantically correct.
As an example, the string returned by moment.utc().format() used to include an offset of +00:00, and it now returns Z. This more closely conforms to the ISO8601 and RFC3339 specifications, so the previous implementation was considered a bug, and it has since been resolved. Most people were fine with this change, as either form should be accepted by all modern parsers, but a few folks complained that this broke their code because they were manually parsing the results via string manipulation, and expecting a numeric value for the offset. We don't consider this a breaking change because the API didn't change, and the resulting string was compliant with the spec both before and after the change - it's just more accurate semantically now.
There are a few miscellaneous other changes like this, and they are all referenced in the changelog. If you edit your question to show which features of moment you are using, then I might be able to provide more details.
My package introduces registry entries. Changes by site administrator should not be overwritten on reinstall of the package.
Many ways to Rome. I chose ftw.upgrade. I like the declarative way of the upgrade step syntax. Its possible to use an upgrade directory for generic setup xml-Files like propertiestool.xml. No need to define handler python code. The upgrade works well. The admin can upgrade from control panel and in my case the new property is added. Insomma: For a new property just these have to be added: an upgrade-step declaration for source and destination version and directory where to find the properties.xml. Thumb up! –
You can pilot what to do when installing a Plone add-on by providing an Extension/install.py file with a install method inside:
def install(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-your.pfile:default')
This way you are driving what Plone should do when installing.
If you need it: the same if for uninstall:
def uninstall(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-example.gs:uninstall')
This way you can prevent the uninstall step to be run when reinstalling.
Warning: as Mathias suggested using quickinstaller -> reinstall feature is bad.
Warning: this will not probably work anymore on Plone 5 (there's open discussion about this).
I think what you describe is one of the problems upcoming with the increasing complexity of Plone's stack, and one of the reasons, why it is not recommended to execute a re-install anymore, but to provide a profile for each version of the Add-On, via upgrade-steps (as Mathias mentioned). That increases dev-time significantly and results in even more conflicts, of my experience. Here are the refering docs:
http://docs.plone.org/develop/addons/components/genericsetup.html#add-upgrade-step
Elizabeth Leddy once wrote an Add-On to ease that pain and I can confirm it does:
https://github.com/ampsport/amp.ezupgrade
And the great guys from FTW, too, I never used it, but looks promising:
https://pypi.python.org/pypi/ftw.upgrade
Neither used this one, even claims to have some extra goodies, like cleanup broken OFS objects and R. Patterson's on it:
https://github.com/collective/collective.upgrade
As we're here, the first good doc I could find about it ~ 1.5 years ago, comes from Uwosh, of course:
http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-generic-setup-upgrade-steps
Another solution can be, to check, if it's an initial- or re-install, and set the properties programatically via a Python-script, conveniently called 'setuphandlers.py', like described in this answer:
How to check, if my product is already installed, when installing it?
That way one can still trigger re-installs without blowing it all up.
Lastly, a lot of the GS-xml-files understand the purge-property, setting it to False, will not overwrite the whole file, just your given props. This might, or not, apply to your case, you can find samples in the above referenced official doc.
It seems that Xunit no longer supports extending TraitAttributes. They have sealed the class.
There are also some other issues with Autofixture's plugin for AutoData() where we can inject random created data through an attribute. There are a few work around's for this, however I am attempting to evaluate this for a larger product overall. I liked the demo's since they could do small things like SQL, Excel, custom Attributes for category.
It seems there was more functionality before the changes. I have looked at the site and still see some of the features are returning and there isn't much information.
Is there a new set of functionality coming out? Or possibly a change that will allow us to recreate the older functionality in a new way? It seems the SQL and Excel have a work around, however I can't find any information about when the latest version will be compatible with "Autofixture with xUnit.net data theories" Nuget package. I really like what I have seen, though I can say I don't like breaking changes when I look at enterprise solutions. I cringe a little when I think about if I had this in place in an enterprise and I had made a lot of custom attributes, or used Moq and Autofixture to populate and now all my tests were broken. So I guess the other question is, does Xunit seem to change a lot with breaking changes? There is the other option of moving Xunit back a version. Though at some point I would need to know if these things would be fixed or if they were permanently removed, since I wouldn't want to spend time using functionality that is being removed.
Another is AutoFixtureMoqAutoDataAttribute that doesn't load without that side Nuget package. With the side nuget packages not being updated.
I guess the end question may be.. Does anyone know of any plans to get these features to work with the current version of xunit so that I can start implementing and then expect to do mass replaces later? Or are these permanently breaking changes where we shouldn't implement anything that is currently missing.
Thank you in advance.
Short answer
If you want to use xUnit.net 1.x with AutoFixture, use AutoFixture.Xunit.
If you want to use xUnit.net 2.x with AutoFixture, use AutoFixture.Xunit2.
Explanation
xUnit.net 2.0 introduced breaking changes, compared to xUnit.net 1.x (e.g. 1.9.2). For AutoFixture, we wanted to make sure that AutoFixture supports both. There are people who want to upgrade to xUnit.net 2.x as soon as possible, but there are also people who, for various reasons, will need to stay with xUnit.net 1.x for a while longer.
For the people who wanted or needed to stay with xUnit.net 1.x for the time being, we wanted to make sure that they'd still get all the benefits of various bug fixes and new features for the AutoFixture core, so we're maintaining two parallel (but feature complete) Glue Libraries for AutoFixture and xUnit.net.
As an example, we've just released AutoFixture 3.30.3, which addresses a defect in AutoFixture itself. This bug fix thus becomes available for both xUnit.net 1.x and 2.x users.
Thus, when you need to migrate from xUnit.net 1.x to xUnit.net 2.x, you should uninstall AutoFixture.Xunit and instead install AutoFixture.Xunit2. As far as I know, there should be feature parity between the two.
Traits
AutoFixture.Xunit and AutoFixture.Xunit2 don't use the [Trait] attribute, so I don't know exactly what you have in mind regarding this.
AutoMoq
Again, when it comes to AutoFixture.AutoMoq, it doesn't depend on xUnit.net, so I don't understand the question here as well. It sounds like a separate concern, so you may want to consider asking a separate question.
As you can guess I am at Qt developer and in the interest of getting up and running with libspotify as quickly as possible I am looking for a Qt wrapper.
I did come across this link https://github.com/romnes/libqspotify but as you can see the source is two years old. I am guessing libspotify has moved on a lot since then.
Does such a wrapper even exist?
Thanks
QSpot appears still to be in development and is based on libqspotify (they have copied the libqspotify sources into their qspotify_src directory). There are some recent commits (August 2012) to that directory, so I'd guess their classes are fresher than the ones you found on GitHub.
The sources of QSpot are found here.
If that doesn't work for you, there is also MeeSpot which is based on a library called libQtSpotify, located in MeeSpot's sources.
There's also Tomahawk. It's also open source