On 20041218T182328-0500, Erinn Clark wrote: > How do you deal with new upstream releases? The general answers I'm getting > seem to be along the lines of "move the debian/ directory to the new > release and tweak it til things work". Is this correct? If so (or if not), > shouldn't there be something in devref or policy about it? Like with many other things in Debian, how you do it doesn't matter as long as you don't break things. Things that should be considered include: - Use a -1 Debian revision number for the new upstream release. - Preserve old changelog entries (sounds obvious, but there have been incidents...) - Add an entry "New upstream release" to the changelog. - Upgrades to the new version should preferably be silent and nonintrusive (existing users should not notice the upgrade except by discovering that old bugs have been fixed and there perhaps are new features) - When an upgrade is necessarily intrusive (eg. it will break existing usage), the upgrade must be noisy (a note in README.Debian or other documentation is generally not enough; NEWS.Debian note may become okay once apt-listchanges with NEWS.Debian support becomes standard operating practice) - Existing Debian changes need to be reevaluated; throw away stuff that upstream has incorporated (in one form or another) and remember to keep stuff that hasn't been incorporated by upstream, unless there is compelling reason not to. I'm probably forgetting something here. It isn't really possible to give comprehensive generally useful procedures - the situation dictates what you need to do. For many packages, for small upstream upgrades, uupdate (from devscripts) can make all necessary changes. Even then, you should be cautious and read upstream release documentation, lurk in upstream user forums and bug tracking systems looking for problem reports, test, test, test and test again. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian
Attachment:
signature.asc
Description: Digital signature