Avoid or Embrace Breakage
In part six of Python Web Application Diary it was noted that soon we'll have a functioning, if basic, journal application. Since I plan to follow the release early release often plan for this particular application -- otherwise a desire for perfectionism will never see the project complete -- now is good time to think about areas of breakage that may occur.
The number one and two issues that come to mind are:
- URL breakage: Will the > 470 journal entries moving over from Pyblosxom to the new application lose their existing URLs? I really dislike the Pyblosxom URL scheme, and will probably vote to go with breaking it. I'm a bad person. It won't happen again. Promise.
- Feed breakage: New URL's and possibly new entry id's tend to do nasty things to feeds, or rather, to the consumers of feeds. I'm tempted to discontinue RSS support while I'm going through this process but need to review my logs to see what the impact of that decision would be.
In fact feed breakage is my larger concern - the last thing I want to do is subject the official or unofficial Python community feed aggregators and their readers to dozens of old and now mostly irrelevant posts.
Ironically that same issue is why I've never asked to be included in either feed, at least not until I moved the data off to another platform.
For now, until I flip the switch, I've disabled the entry / item content in my existing Atom and RSS feeds by creating empty Pyblosxom flavour files for story.xml and story.rss -- this will result in no blog entries being published via either feed. I've also added to the description element in both feeds a notice:
<description>$blog_description :: Feed off-line while upgrades being done </description>
Coming up in part seven of the series, accomplishing enough to flip the switch.