Tony Kelman

Since this repo will contain additional juleps as time goes on, best to preface issue titles with which julep they're about.

Keeping track of whether you're using the development version or an installed version needs to be made extremely clear. `Pkg.status()` does a decent job right now, but if Pkg3 doesn't...

`Config.toml` sounds to me a bit like something the user might be expected to modify to tweak optional settings, which it sort of would be for projects but not really...

Project-specific environments mean you don't have to worry about packages getting held back by things you aren't currently using. But unless we somehow enable simultaneous loading of multiple versions of...

Yeah upper bounds on Compat would cause things to go slightly haywire. Every Compat tag would have to be followed by a few hundred upper bound bumps.

I don't think it's that bad to have the registry responsible for compatibility information, since that's the living changing source of versions. Compatibility constraints are often correct when created and...

Enforcing upper bounds is the issue here. They can be recommended, but upper bounds lead to disallowing combinations of packages from being installed together unless one or both authors have...

Making the definitive source of compatibility information come from something immutable, the original released package source, is the other issue here. If multiple registries is a thing that works fine,...

There are 3 possible states for any particular version of a dependency: 1. known to be compatible (aka has been tested) 2. known not to be compatible 3. not yet...

> I still think that it makes sense for the "atoms" of compatibility to be minor versions with exclusions for specific broken patches. I can't think of a legitimate situation...