pgenv 1.3.2 is out!

Today we released version 1.3.2 of pgenv, the binary manager for PostgreSQL.
This release fixes a quite subtle bug in the handling of the configuration that prevented custom settings to be correctly loaded back into the running system. Users are encouraged to upgrade as soon as possible.

A description of the problem

17bob17 noticed the issue: when you edited your configuration file, either the default or a per-version one, and changed settings in a (Bash) array, the configuration was not correctly loaded.
It took a lot of time to figure out that the problem was not directly in the way the configuration was loaded, rather in the way the configuration was stored.
When pgenv acquired the configuration settings as arrays, it started using declare -p as a way to print out a Bash compatible representation of the array, and such representation was stored in the configuration file. The problem was that declare -p assumes you want to use declare back when you re-evaluate the variable (array), and so placed a declare -a as the output.
The configuration is then loaded within the pgenv_configuration_load function, and declare run into a function has the same effect as local, that is it lexically scope the variables. Therefore, as soon as pgenv_configuration_load ends its job, the lexically scoped variables are gone and the old (previous) one are kept with their default value. It is a boring masquerading problem due to inner contexts.
One possible solution could have been to use -g as a flag to declare, so to force the variable to be global and therefore not lexically scoped, but such flag is not everywhere in different Bash versions and implementation.
The -x flag to declare, to export the variable, did not have any effect too.

Therefore, the current release removes the use of declare at all when the configuration is sourced back (loaded).