You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we have a system of 6 dependency tiers within the Hydra code base, as described here: tier-0 for kernel type definitions and selected constants, tiers 1 through 3 for other kernel code, tier-4 for tests and language modules, and tier-5 for third-party code. This layer cake is a little too thick IMO, and could probably be compressed. In particular, tier-3 is almost empty and could probably be combined with tier-2. Also, I don't think there is much value in distinguishing the built-in language modules from third-party code in terms of dependencies. Finally, it is a little odd that Hydra Core isn't properly in any tier, including tier-0. Here is the plan going forward:
Currently, we have a system of 6 dependency tiers within the Hydra code base, as described here: tier-0 for kernel type definitions and selected constants, tiers 1 through 3 for other kernel code, tier-4 for tests and language modules, and tier-5 for third-party code. This layer cake is a little too thick IMO, and could probably be compressed. In particular, tier-3 is almost empty and could probably be combined with tier-2. Also, I don't think there is much value in distinguishing the built-in language modules from third-party code in terms of dependencies. Finally, it is a little odd that Hydra Core isn't properly in any tier, including tier-0. Here is the plan going forward:
Tier-4 isn't so much a single tier as an "everything else" bucket, regardless of dependency structure.
The text was updated successfully, but these errors were encountered: