I have a major version bump for acf-weblog in the works. Unfortunately, it's not
backwards compatible. Since acf-weblog uses postgres, it got me thinking about
how the upgrade from postgres 8 to 9 went. In Alpine Linux 2.1, we released
postgresql 9.0. Since the data directory moved, a simple 'apk upgrade' from
postgres 8 to 9 broke any existing postgres databases. There was no real warning
for users. The release notes
(http://www.alpinelinux.org/wiki/Release_Notes_for_Alpine_2.1.0) mentioned the
version bump, but nothing about the incompatibility. The only way they would be
aware of the problem was with insider knowledge about postgres. I had several
users run into this problem.
What is the proper way to handle upgrades like this?
1) Put the upgraded package in a newer version of Alpine Linux (ie 2.2) with a
note in the release notes? Let the user beware.
2) Add upgrade instructions to the Alpine release notes? (like
http://www.alpinelinux.org/w/index.php?title=Template:UpgradeTo2)
3) Try to create pre/post install scripts to make the upgrade seemless?
I know option 3 would be a lot of work, considering the number of packages we
now have, but it's the 'nice' thing to do. Thoughts?
Ted Trask
P.S. Should we go back and try to make the postgres upgrade cleaner for future
users who upgrade to 2.1?
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Sat, 26 Feb 2011 03:36:07 -0800 (PST)
Ted Trask <ttrask01@yahoo.com> wrote:
> I have a major version bump for acf-weblog in the works.
> Unfortunately, it's not backwards compatible. Since acf-weblog uses
> postgres, it got me thinking about how the upgrade from postgres 8 to
> 9 went. In Alpine Linux 2.1, we released postgresql 9.0. Since the
> data directory moved, a simple 'apk upgrade' from postgres 8 to
> 9 broke any existing postgres databases. There was no real warning
> for users. The release notes
> (http://www.alpinelinux.org/wiki/Release_Notes_for_Alpine_2.1.0)
> mentioned the version bump, but nothing about the incompatibility.
> The only way they would be aware of the problem was with insider
> knowledge about postgres. I had several users run into this problem.
The list of app in the mentioned release notes was thought as: This is
the list of apps that is not compatible with current. If you run any of
those you might want check with upstream on how to upgrade.
And for postgresql, they have always required dump/restore for
upgrading (except when you upgrade from x.y.z to x.y.z+1)
>
> What is the proper way to handle upgrades like this?
>
> 1) Put the upgraded package in a newer version of Alpine Linux (ie
> 2.2) with a note in the release notes? Let the user beware.
> 2) Add upgrade instructions to the Alpine release notes? (like
> http://www.alpinelinux.org/w/index.php?title=Template:UpgradeTo2)
> 3) Try to create pre/post install scripts to make the upgrade
> seemless?
4) ship a package named postgresql8.4 *and* postgresql9.0 which both
can be installed at the same time.
> I know option 3 would be a lot of work, considering the number of
> packages we now have, but it's the 'nice' thing to do. Thoughts?
One of the new things in postgresql-9 was a tool that should make
online upgrades easier iirc. We might want check that out.
But postgresql upgrades have always been tricky. I remember when
upgrading a mediawiki install, it was not as simple as just
dump/restore.
For smaller things I'd recommend using sqlite.
> Ted Trask
>
> P.S. Should we go back and try to make the postgres upgrade cleaner
> for future users who upgrade to 2.1?
We could make a pre-upgrade script that checks if postgres is running
and exit with error if it is.
Something like:
# if we upgrade from something older than 9.0...
if [ "$(apk version -t $2 9.0)" = "<" ]; then
# check if it is running
if ! rc-status -q postgresql; then
exit 0
fi
echo "You should do a pg_dump and stop postgres service before
upgrading and pg_restore afterwards. Please consult the
postgresql documentation" >&2
echo "Aborting upgrade" >&2
exit 1
fi
exit 0
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---