Comment 14 for bug 1902945

So if you are referencing an exact version of the charm, this could be ok.
That said I'm not sure that the new charm store supports the same revision
semantics of the existing store. (Because of how the new store tracks
architecture versions for charms, I'm not sure that revision numbers that
worked in the old store continue to work once the data is migrated.)
That said, we still need to understand what track the version is on for
purposes of things like "juju upgrade-charm app" knowing the channel.

On Fri, Nov 6, 2020 at 12:20 PM Pete Vander Giessen <
<email address hidden>> wrote:

> I think that this bug reflects some difficulty in the transition to
> handling channels more like snaps.
>
> I agree that the correct behavior is to only deploy charms from edge if
> the operator has explicitly accepted the edge risk. But that's not how
> things used to work, and existing bundles will break.
>
> Do we want to push off the change in behavior for Juju 3.0.0? That would
> allow 2.9 to essentially operate like the rest of the 2.x series. The
> new charm store is going to be behind a feature flag, anyway.
>
> The only catch is that the charm store shim may break us, even if we
> make an effort to support the old behavior ...
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1902945
>
> Title:
> 2.9rc2: kubeflow deploy fails on microk8s
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1902945/+subscriptions
>