2.7.12 #1107
2.7.12 #1107
Conversation
| @@ -7,7 +7,7 @@ SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd ) | |||
| deb_dir="/tmp/postgresml-python/deb-build" | |||
| major=${1:-"14"} | |||
|
|
|||
| export PACKAGE_VERSION=${1:-"2.7.10"} | |||
| export PACKAGE_VERSION=${1:-"2.7.12"} | |||
There was a problem hiding this comment.
You don't need to release a new version of this package unless you've changed python deps since the last version.
There was a problem hiding this comment.
It seems like a nice convenience for end users, if all package versions for the project align.
There was a problem hiding this comment.
That's not how this works or why we split the python deps into their own package. This allows for us to upgrade the extension much quicker without having to download and install gigabytes of dependencies.
There was a problem hiding this comment.
That split is causing issues with consistent updates.
There was a problem hiding this comment.
We have infrastructure in place to manage that. It wasn't used, which caused the issue with consistent updates. We can make it mandatory by bundling everything into the same package, but we've done that previously and it was pretty inefficient for rolling updates.
An action item on my side is to document the current infrastructure and provide guidebooks on how to upgrade and release these packages.
There was a problem hiding this comment.
As I wrote the docs I remembered a couple more reasons why I split those packages and I'm pretty confident in my decision now. On the postgresml/postgresml side of things, we're pretty covered I think, as long as we follow release procedures (#1013 (comment))
There was a problem hiding this comment.
Having code that implements the procedure seems like the next step after a manual procedure is documented.
No description provided.