upgrade hook should get access to previous version numbers of the charm

This is a good idea.

As a minor, it's not clear that the *new* version is necessary (the new version is always the one the script was bundled with).

<hazmat> and people do want access to at least the old charm version, which we don't currently provide
<niemeyer> hazmat: I'm concerned about introducing that
<hazmat> niemeyer, even providing just the number?
<niemeyer> hazmat: Yes
<niemeyer> hazmat: precisely because people will use the number, and people are generally bad at figuring exactly what number they should use
<niemeyer> hazmat: We should instead recommend to people that they look for facts rather than charm numbers
<niemeyer> hazmat: E.g. "Was this file on the tree?"
<niemeyer> hazmat: Very often, authors of packages think about upgrades happening from the previous version
<niemeyer> hazmat: and forget that real world users will often leap multiple versions forward

Excerpts from Kapil Thangavelu's message of Mon Jan 16 15:01:27 UTC 2012:
> <hazmat> and people do want access to at least the old charm version, which we don't currently provide
> <niemeyer> hazmat: I'm concerned about introducing that
> <hazmat> niemeyer, even providing just the number?
> <niemeyer> hazmat: Yes
> <niemeyer> hazmat: precisely because people will use the number, and people are generally bad at figuring exactly what number they should use
> <niemeyer> hazmat: We should instead recommend to people that they look for facts rather than charm numbers
> <niemeyer> hazmat: E.g. "Was this file on the tree?"
> <niemeyer> hazmat: Very often, authors of packages think about upgrades happening from the previous version
> <niemeyer> hazmat: and forget that real world users will often leap multiple versions forward
>

Ignoring the facts of the system in a maintainer script is also a bug,
but not one caused by having version numbers.

Whats helpful is having the version number so you can make some
assumptions about the user's intentions.

If I know that the version is lower than one where a permissions change
is asserted, then I can safely change the permission from what it was
in previous versions of the package to what I, the package maintainer,
suggest it should be now. So I still have to observe the facts before
making changes, but I can do it confidently.

If I don't know the previous version that I'm upgrading from, then I
have to assume that the old permissions were set explicitly by the user,
and I would have to leave them alone no matter what.

We can suggest that charms are a firmer assertion of policy than package
maintainer scripts, in which case we should be more heavy handed with
these changes and revert any user changes anyway, so I'm comfortable
with not having the version available. This is also simpler since we
will not have the luxury of a single version stream that is guaranteed
to advance like the changelog of packages.

Re-targeting to Juju 2.x

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.