borgbackup (1.0.0~rc1-2) unstable; urgency=medium

  Please review the following compatibility notes from upstream to prepare your
  installation for the upcoming 1.0 release.
  .
  Be aware that issue numbers are not Debian bugs, but rather references
  to the upstream issue tracker at
  https://github.com/borgbackup/borg/issues/<number>
  .
  * change encryption to be on by default (using "repokey" mode)
  * moved keyfile keys from ~/.borg/keys to ~/.config/borg/keys,
    you can either move them manually or run "borg upgrade <REPO>"
  * remove support for --encryption=passphrase,
    use borg migrate-to-repokey to switch to repokey mode, #97
  * remove deprecated --compression <number>,
    use --compression zlib,<number> instead
    in case of 0, you could also use --compression none
  * remove deprecated --hourly/daily/weekly/monthly/yearly
    use --keep-hourly/daily/weekly/monthly/yearly instead
  * remove deprecated --do-not-cross-mountpoints,
    use --one-file-system instead
  * disambiguate -p option, #563:
    -p now is same as --progress
    -P now is same as --prefix
  * remove deprecated "borg verify",
    use "borg extract --dry-run" instead
  * cleanup environment variable semantics, #355 the environment
    variables used to be "yes sayers" when set, this was
    conceptually generalized to "automatic answerers" and they
    just give their value as answer (as if you typed in that value
    when being asked). See the "usage" / "Environment Variables"
    section of the docs for details.
  * change the builtin default for --chunker-params,
    create 2MiB chunks, #343 --chunker-params
    new default: 19,23,21,4095 - old default: 10,23,16,4096
  * one of the biggest issues with borg < 1.0 (and also attic)
    was that it had a default target chunk size of 64kiB, thus
    it created a lot of chunks and thus also a huge chunk management
    overhead (high RAM and disk usage).
  * please note that the new default won't change the chunks that you
    already have in your repository. the new big chunks do not
    deduplicate with the old small chunks, so expect your repo to
    grow at least by the size of every changed file and in the
    worst case (e.g. if your files cache was lost / is not used)
    by the size of every file (minus any compression you might use).
  * in case you want to immediately see a much lower resource
    usage (RAM / disk) for chunks management, it might be better to
    start with a new repo than continuing in the existing repo
    (with an existing repo, you'ld have to wait until all archives
    with small chunks got pruned to see a lower resource usage).
  * if you used the old --chunker-params default value (or if you
    did not use --chunker-params option at all) and you'ld like to
    continue using small chunks (and you accept the huge resource usage
    that comes with that), just explicitly use borg create --chunker-params=10,23,16,4095.
  * archive timestamps: the 'time' timestamp now refers to archive
    creation start time (was: end time), the new 'time_end' timestamp
    refers to archive creation end time. This might affect prune if your
    backups take rather long. if you give a timestamp via cli this is
    stored into 'time', therefore it now needs to mean archive creation start time.

 -- Gianfranco Costamagna <locutusofborg@debian.org>  Mon, 08 Feb 2016 18:30:40 +0100