Keeping production current.

[didactic_cudgel]

I run a production DW-powered site and I want to keep it up to date with the latest code fixes and features.

In asking #dreamwidth-dev about following this procedure: http://wiki.dwscoalition.org/notes/Dev_Maintenance firefoxfey recommended that I find out what the latest post-release final tag is an update only to that tag to avoid getting untested dev features, but didn't know the procedure. I was advised to ask here and so I am :)

If I want to keep my code current, but reduce the chance of pulling down untested code, how do I find and limit code to the post-release final tag?

Also, Fey suggested making sure that I'm aware of any database changes. Are those announced separate from code pushes?

Comments

[kareila]

I think you would have to manually cd into cvs/dw-free, do "hg tags" to see what the most recent tag is (currently 1.0.0) and then "hg update -r [tagname]" to get that revision. Then use cvsreport -sync as normal to sync the files from the cvs directory to the working directory. We should probably update the cvsreport script to make this easier.

As for database changes, we've only had one of those so far and we've announced it in this community using the "dversions" tag.

[exor674]

Well, there are occasional simple database changes that can be done with db-update...
For those, I'd just run cvsreport itself ( not with -sync ) and if update-db-general.pl, then you've got a simple changes.

db-update should be ran every update, anyway.

Any more complicated changes will be as kareila said.

It may be safest to wait a week or two after the code push before updating to the latest tag ( and stay one push behind until then ), so we can catch any lingering issues ( we are already on 1.0.1 due to some issues from the push )

For a production site, to minimize surprises:

• You are going to want to have *all* of your configuration files copied into cvs/<dir I had you create>/etc, and compare the diffs between versions to see if there are any important changes.


• You should probably run cvsreport first w/o args before -sync, to make sure you know what is changing.

[exor674]

There's no explicit handling of -local, you could name your scheme didactic-cudgels-awesome-grad-horizontal-variant-of-science or whatever -- which is why you have to name the local one when you want to use it ( see http://www.dreamwidth.org/?usescheme=celerity v.s. http://www.dreamwidth.org/?usescheme=celerity-local )

Certain things look for a local file, those being, the database updater for the s2 layer list and update-db-general, as well as a few other things.


7. Yeah, Tankfully most others are very rarely updated, but you don't want to suck something in accidentally.