On Fri, Oct 31, 2014 at 8:35 AM, Curtis Hovey-Canonical <[email protected]> wrote: > On Thu, Oct 30, 2014 at 2:10 PM, Eric Snow <[email protected]> wrote: >> What would be the best approach for deprecating the old backup plugin? >> I was going to simply gut it (it's a bash script) and stick in a >> deprecation warning message and a call to "juju backups create >> --download". However, jam rightly pointed out to me that this may be >> a sticky situation (as described above). I'd really like to find a >> way to eliminate the old backup implementation. Thoughts? > > Look before you leap. Call juju status and check that the version is > 1.21.+ and use new command, else old command.
Good idea. > We expect new clients to > manage old state-servers during transitions. The transition my be long > if the enterprise is not upgrading their envs. I think we are stuck > with the old implementation for as long as we support trusty. Yeah, that's what I figured but hoped wasn't the case. > > Users do not know that backup is a bash script... > juju backup > is the command, so we can write an alternate plugin that checks the > state-server version, then either calls to new command or the old > script which is renamed, If we rename/change juju-backup.bash, we need > a simultaneous packaging change. Since it is transparent to users and otherwise mostly irrelevant, I'll leave the filename alone and add the conditional operation to the existing script. Am I okay with adding a deprecation warning message (to stderr) that instructs "juju backup" users to use "juju backups create" instead? I'm not sure what precedent there is for doing so with our CLI. -eric -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
