The Dart FakeAsync package seems to have the same functionality as quiver.testing.async inside the Quiver package so as a Flutter and Dart app developer I'm confused as to which one to use?
Is one supposed to be used over the other in particular circumstances? nothing in the documentation for either package gives any guidance on this either. Both packages also seem to be authored and maintained by members of the Google Flutter and Dart teams which makes it even more confusing.
The only thing I can see is that FakeAsync package is last updated in July 2018 while Quiver was in Nov 2019, so is FakeAsync deprecated? if so it's not labelled as such. And also a small number of core packages currently depend on FakeAsync, while a very large number of diverse package depend on quiver (though can't know if they depend on quivers testing.async).
I tried (with limited success) to dig into the muddled history.
FakeAsync was a third-party contribution to quiver, and a few months later, the author forked package:fake_async from quiver's version. I don't know what the rationale was for having two separate implementations, but I could guess that perhaps the author wanted to have more direct control over the code. (In other words, package:fake_async initially was not authored nor owned by Google.)
I asked around, and my understanding is that package:fake_async stopped being maintained, and Google's Dart team ended up taking ownership of package:fake_async so that it could be updated for Dart 2.
From package:fake_async's changelog, it does appear that it was meant to be a superset of quiver's version, but the implementations have since diverged so that it's no longer fully backward compatible.
At this point, I personally would use the quiver version: it's better maintained and is what Flutter uses, so I expect that it has much more inertia behind it.
I've also filed https://github.com/dart-lang/fake_async/issues/16 requesting that guidance be added to the documentation.
Update
I now recommend using package:fake_async. Flutter moved in the other direction and switched to using package:fake_async instead. package:fake_async has been updated to be a proper superset of of the quiver version. Also see https://github.com/google/quiver-dart/issues/590.
Related
I am trying to download MRTK by following https://microsoft.github.io/MixedRealityToolkit-Unity/Documentation/GettingStartedWithTheMRTK.html. But on the Assests folder on GitHub for MRTK, I cannot find the two packages below mentioned:
Microsoft.MixedRealityToolkit.Unity.Examples.unitypackage
Microsoft.MixedRealityToolkit.Unity.Foundation.unitypackage
Did I miss anything simple?
The exact naming of the packages is going to be different from release to release because the version number increases each time a new version is published.
The docs will say something like
"Microsoft.MixedRealityToolkit.Unity.Examples.unitypackage"
But the latest right now actually is named:
"Microsoft.MixedReality.Toolkit.Unity.Examples-v2.0.0-RC2.1.unitypackage"
It's kinda done this way to reduce the number of things that have to get changed with each release (i.e. making sure that every single instance of the naming of a version stays up to date can be somewhat risk prone in terms of missing things, so when possible if we can just say "grab the latest package" or "grab the thing that is the examples package" it also helps to reduce the number of version mismatches out there).
So to be super clear here, basically go to the releases page:
https://github.com/microsoft/MixedRealityToolkit-Unity/releases
Scroll to the bottom of the the latest release and expand the Assets expando and get the two unitypackages:
https://github.com/microsoft/MixedRealityToolkit-Unity/releases/download/v2.0.0-RC2.1/Microsoft.MixedReality.Toolkit.Unity.Examples-v2.0.0-RC2.1.unitypackage
https://github.com/microsoft/MixedRealityToolkit-Unity/releases/download/v2.0.0-RC2.1/Microsoft.MixedReality.Toolkit.Unity.Foundation-v2.0.0-RC2.1.unitypackage
Would it be helpful to document the packages as
Microsoft.MixedRealityToolkit.Unity.Foundation[Version].unitypackage
For example: easeljs-NEXT.js
I sense that the NEXT in caps has meaning, but don't know what.
I've tried searching on Bing, for example "what does NEXT mean in a filename".
Also tried a similar search here in stackoverflow with no result.
CreateJS contributor here.
The "NEXT" naming is the file convention we have chosen for the upcoming/in-progress version of CreateJS libraries. Typically, we commit changes/fixes over a period of time, and then eventually tag a new version that gets put on the CDN and (ideally/eventually) included in an updated version of Adobe Animate.
Due to our testing process, and inter-reliance across libraries (Preload, Sound, Easel, Tween), we are pretty conservative when it comes to making official builds. This is our way of making sure there are easy-to-use, compiled builds in GitHub with the latest features, fixes, and documentation. They aren't "official releases", as they might not play well with other content.
Releases:
easeljs.js (with comments and whitepace, good for testing)
easeljs.min.js (minified)
Upcoming/Latest
easeljs-NEXT.js
easeljs-NEXT.min.js
Prior to version 1.0, we used version names:
easeljs-0.6.2.min.js
easeljs-0.6.2.combined.js (the old testing version, not included on CDN)
You can also find "Combined" scripts on the CDN (and other CDNs) that have all 4 libs included. We didn't build NEXT versions of these, since they would be prone to issues:
1.0.0/createjs.js
1.0.0/createjs.min.js
Again, before 1.0, we used a version, which for combined libs was a release date, since they actual version numbers of the libs didn't all align.
createjs-2015.11.26.min.js
createjs-2015.11.26.combined.js
We are working on improving our release schedule, so there are more official releases than in the past. Hope that provides some insight!
Apologies if this question is being posted into the wrong space - it doesn't feel quite right for SO, but I don't know of a better place.
I have a public nuget Package (EnumStringValues ... plug, plug plug) which I'm making a change to.
The change doesn't change the API signatures - the old code will still compile.But it does change behaviour in an edge case - mostly the result is that a usage that would previously have generated an exception now performs a different default behaviour. There's also a TryParse() call, which will (in this edge case) change a (non-exception) fail case into a success case.
The edge cases are "you've used this library in a way that it wasn't really intended to be used". i.e. I've slightly increased the intended use-scope of the library.
Is that a breaking change? and does it thus demand a new MAJOR version?
Or is it merely a minor change that is "backwards compatible".
My first instinct is to say it's a change to the behaviour of existing calls and therefore a breaking change.
Thoughts?
Given the following
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards-compatible manner
PATCH version when you make backwards-compatible bug fixes.
I would say that your change is not backwards compatible. People who belong to your edge case group will have their expected functionality changed by your new package. In light of this I would say it is a new major version
I've got a (dirty) production installation of Simple Machines Forum (SMF 1.1.13). It was a clean install, once... about five years, twenty updates, and 40 mods ago. Not to mention the custom code that was patched directly into the code base. This started as a for-fun side project, and didn't have any code management practices at the get-go.
Now SMF 2 is (getting closer to) going live, and I want to upgrade. But without leaving the custom features behind.
Keep reading, this is a general software management question, not an SMF support question...
I'm trying to figure out the best way to port the custom features into the new code branch.
In some cases, the custom 1.1.x functionality will already exist in 2.0. Yay, no work for me!
In some cases, there will be mod packages versioned for 2.0, and I can just install them directly on a clean SMF 2 build. Yay, minimal work for me!
In some cases, the code port will be fairly straightforward between the two versions (e.g. a few small changes in queries or global variable construction). (I've ported a few features/mods back from 2.0 to 1.1.x, so I'm starting to get familiar with it.)
In some cases, I'm just going to have to redevelop the features mostly from scratch.
Those last two options are gonna be hard to manage.
Any suggestions on how to port a large number of changes from one branch to another?
When it's not my own in-house code, that is. Here's my initial plan:
Diff between a clean version of 1.1.x and my "dirty" production code
Map each line diff to a feature ("That code update is the custom tagging feature, gonna have to port it line by line, and that one over there is the gallery, I can probably install an updated mod.") This would be SOMUCHEASIER if there were a diff tool that generated a consolidated report, instead of having to go through scores of files one at a time. Google and SO searches didn't find a tool like that-- Is there one?
Install a clean 2.0 branch
Install the available updated mods
Roll up my sleeves and go through my diffs feature by feature (this? is why I need the consolidated diff report. It would be hell to do page by page.) and build them back in.
Any better ideas? (Pointers to release management info are welcome, though of course with the caveat that it's not actually my code so I have limited control.)
Otherwise? I fear my options are ditch the custom features (not really feasible) or stay on the old branch. Both suck. Help!
tl;dr: Point me to a diff tool that will do consolidated file-by-file diff reports for entire directories. And/or help me figure out an easier way to migrate my custom code.
Your plan is generally the most practical approach, although I would say that you're heading in the wrong direction by looking for code-level differences. With no version control over the project lifetime and with no concise record of applied changes, in examining differences at the code level you are looking for a level of detail that may not give you the information you need to apply the same changes to a new implementation.
Move away from thinking of code-level changes and consider application-level feature and behavioural changes. What features have your changes introduced? In what ways does your application now behave differently due to your changes?
You say that there have been many unversioned changes over a long period - you will fail to find all the changes no matter what tools you have at your disposal and you will still need to consider the feature and behavioural changes that exist to fully represent the same features and behaviours in any upgraded implementation.
You know your application well, you use it and you do appreciate the feature changes that you have introduced even if you may not realise this.
Install a vanilla 2.0 release
Apply all appropriate mods
Apply relevant styling
Use the new system, note the differences in behaviour and develop from this a set of required features
Your feature set does not need to be complete - don't stall at the stage of trying to figure out all required changes, this will take too long.
Apply features gathered from most recent feedback (ideally through revertable mods)
Note the differences in behaviour at develop from this a set of required features
Repeat
I am having much confusion over the process of upgrading version numbers in dependent plug-ins, features, and products in a fairly large eclipse workspace.
I have made API changes to java code residing in an existing plug-in and thus requires an increase of the Major part of the version identifier. This plug-in serves as a dependency to a given feature, where the feature is later included in a product. From the documentation at http://wiki.eclipse.org/Version_Numbering, I understand (for the most part) when the proper number should be increased on the containing plug-in itself.
However, how would this Major version number change on the plug-in affect dependent, "down-the-line" items (e.g., features, products)?
For example, assume we have the typical "Hello World" setup as follows:
Plug-in: com.example.helloworld, version 1.0.0
Feature: com.example.helloworld.feature, version 1.0.0
Product: com.example.helloworld.product, version 1.0.0
If I were to make an API change in the plug-in, this would require a version update to be that of 2.0.0. What would then be the version of the feature, 1.1.0? The same question can be applied for the product level as well (e.g., if the feature is 1.1.0 OR 2.0.0, what is the product version number)?
I'm sure this is quite the newbie question so I apologize for wasting anyone's time and effort. I have searched for this type of content but all I am finding is are examples showing how to develop a plug-in, feature, product, and update site for the first time. The only other content related to my search has been developing feature patches and have not touched on the versioning aspect as much as I would prefer. I am having difficulty coming into (for the first time) an Eclipse RCP / PDE environment and need to learn the proper way and / or best practices for making such versioning updates and how to best reflect this throughout other dependent projects in the workspace.
If you would like to apply the same versioning systems to feature and product, then you would set feature and product to 2.0.0 when one of the plugins go to 2.0.0. That would communicate to whoever is consuming your feature or product that there is a breaking API change inside it somewhere.
On the other hand, there is no requirement to apply the same versioning convention. You can version your bundles following that convention to properly communicate your API changes and then turn around and use more marketing-sensible versions for product/feature. Keep in mind that user will see product/feature version more than they will individual bundle version.
I've seen it done both ways effectively. There isn't really a right or wrong way on this.