~alpine/devel

1

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

Details
Message ID
<759731.20927.qm@web130104.mail.mud.yahoo.com>
Sender timestamp
1298720167
DKIM signature
missing
Download raw message
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
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20110226154837.18a10a68@alpinelinux.org>
In-Reply-To
<759731.20927.qm@web130104.mail.mud.yahoo.com> (view parent)
Sender timestamp
1298735317
DKIM signature
missing
Download raw message
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
---
Reply to thread Export thread (mbox)