Edge Cases
Edge cases are indeed annoying, but also solving them making the product unique and powerful. There isn’t a perfect solution for each edge case but better solutions. It is recommended for the team to document the found edge cases here and record the solutions at the time, so that they can be reviewed and potentially revised in future.
Dependency Installation/Uninstallation
(DONE!)Install a package that has dependency package already existed ( Replace the package or delete it? For example, a dependency package 0.99 version kangaroo installed on the machine, however, the incoming dependency package contains 0.98 version kangaroo, this is a tricky situation where which one or both to preserve? ). Solution: coordination in the team, place dlls accordingly. Also, check out the Create a package section to learn more.
(DONE!)Uninstall a package that is dependent by another package / other packages -> need a message box prompted to user. Should the package be deleted?? If the user forces to delete this package although it is known to the user the package is dependent on other packages? Can user opt out? Solution: Users won’t be able to uninstall dependency packages, hence, they can’t see dependency packages by default unless they change the view setting to see them.
(DONE!)Currently, packages? -> The scenario -> User becomes inclined towards one of the dependency package, and when uninstalling the target package, the user wishes to preserve the dependency package (because most of the projects the user did also rely heavily on solely the dependency package). Now, when the target package is deleted, the dependency packages are deleted altogether as well, this will cause issue in the previously mentioned scenario.
(DONE!)Compare each asset of a package dependency to check if the specific asset already installed to the target location, currently, the program skips if detecting one of the assets already installed, which might skip the additional new assets.
(DONE!)Uninstall a package, one of its dependency package is required by another installed package. We should skip this particular dependency package and deleting all other dependency packages. However, this shouldn't apply to the target package to uninstall. If the target package is required by another package as dependency, nothing should be deleted.
(DONE!)Need a recursive method to visit all the parent packages, which should be similar to the current recursive method that finds all the downstream children packages.
(DONE!)If Package was installed as dependency in a particular version that is required by the Application package, it shouldn't be "updated" to lower / higher version. Refer to edge case No.2
Automated Updates
If the entire package is deleted from the website, preserve the package on the user's computer, and display it in the installed tab? Currently, Drop crashes if package information on the backend doesn’t match with the user’s desktop application. Need a way to handle this unmatching instance.
The current BackgroundUpdateChecker is a thread itself running separated from the main thread, which causes the bug where the BackgroundUpdateChecker couldn't find the Version.json and Package.json while the package is still being installed. This produces errors and terminates BackgroundUpdateChecker.
Package WIP
(DONE!)If the user chooses to only see packages that are not in WIP, will there be a situation in which the Application package contains dependency packages that are WIP? In that case, should those dependency packages be installed, or should the Application be ever installed at the first place? Solution: WIP packages shouldn’t be used as dependencies.
Last updated