Subject: [alpine-devel] Proper way to handle major version upgrade for a package

From: Ted Trask <[email-masked]>
Date: Sat, 26 Feb 2011 03:36:07 -0800 (PST)

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:  [email-masked]
Help:         [email-masked]
---

---

From: Natanael Copa <[email-masked]>
Date: Sat, 26 Feb 2011 15:48:37 +0000

On Sat, 26 Feb 2011 03:36:07 -0800 (PST)
Ted Trask <[email-masked]> 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
> (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)

> 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.

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

---