Add eol-runtime-upgrade-dependency-hell-migration article

Author: webstackdev

COVERS.md

@@ -401,3 +401,25 @@ Create an image of a scale balancing "Observability Value" on one side (represen
 ### Prompt 5: The Haystack Problem
 
 Design an image of a massive haystack (routine traces) with several golden needles (interesting traces) hidden within. A smart detection system with sensors identifies and extracts only the needles without processing the entire haystack. Style: needle in haystack metaphor, agricultural meets technology, warm golden tones, 16:9 aspect ratio.
+
+## eol-runtime-upgrade-dependency-hell-migration
+
+### Prompt 1: The Dependency Maze
+
+Create an image of a developer navigating a complex maze where the walls are made of stacked package boxes labeled with version numbers. Some paths are blocked by red "EOL" barriers. A glowing path through the maze represents the upgrade path. Style: isometric 3D maze, package box aesthetic, red barriers, golden path, 16:9 aspect ratio.
+
+### Prompt 2: The Iceberg of Dependencies
+
+Design an image of an iceberg where the tip above water shows 3-4 direct dependency boxes, but below the waterline is a massive tangle of hundreds of transitive dependency boxes, some glowing red as blockers. Style: iceberg cross-section, package visualization, blue water tones, red warning highlights, 16:9 aspect ratio.
+
+### Prompt 3: The Version Timeline
+
+Illustrate a timeline showing runtime versions from EOL (grayed out, crumbling) through current (stable) to future (bright). Applications are shown migrating along the timeline, with some stuck at EOL boundaries. Style: horizontal timeline, version progression, decay-to-renewal gradient, 16:9 aspect ratio.
+
+### Prompt 4: The Upgrade Surgery
+
+Create an image of a surgical operation where surgeons (developers) are carefully replacing components in a complex system (application). Monitors show dependency graphs, and replacement parts are staged nearby. One surgeon holds up an old component labeled "EOL". Style: medical operating theater, technical precision, clean aesthetic, 16:9 aspect ratio.
+
+### Prompt 5: Breaking the Chains
+
+Design an image of chains connecting runtime boxes (Node 16, .NET Framework, CentOS 7) to an application, with some chains being cut by bolt cutters, freeing the application to float toward newer runtime boxes above. Style: chain and lock metaphor, breaking free visual, upward movement, 16:9 aspect ratio.

_TODO.md

@@ -192,6 +192,7 @@ To overlay an article title and published date on a cover image, use CSS positio
 - Numbering for ordered lists breaks when there are code blocks in between numbered list elements, like in src/content/articles/cdn-edge-caching-cache-keys-vary-headers/index.mdx
 - Add a cloud of tags on articles list view at top for quick navigation. Add a ToC for featured tags so it's available on mobile, but with something different on desktop view - maybe hide tag cloud on mobile, and show it with an HR between all tags cloud and featured on desktop.
 - The "❌" symbol is not showing in sql code block, it's rendering as a plain "X". But "✅" renders okay. src/content/articles/database-schema-migrations-continuous-deployment-zero-downtime/index.mdx
+- Use an in-project Image component to wrap Astro's Image and Picture. Show a magnifying glass with a "+" for the cursor on hover, and a modal to show a magnified view of images on click.
 
 ## Reading position indicator
 
@@ -330,6 +331,8 @@ some config
 
 For code examples like YAML config, use a concrete tool context so readers can understand where they would deploy or use the code. A single comment line or reference to the tool, or a descriptive file name, is sufficient. Prefer showing usage for AWS but a small amount of variety showing open source tools is the optimal case. So, for example, if there were four config examples, three might apply to AWS and one to an alternative tool. Do not include multiple tables, code blocks, or mermaid diagrams in a row without text between them to break them up. Do not import the Callout component, it is automatic. Don't use code blocks just for presentation, only for true pseudocode or real code examples. If there is info in a code block in the outline that is only for presentation purposes, redo it in a better presentation format.
 
+We are writing an article based on an outline, not just merely adding a few lines of text around existing outline elements like code blocks, diagrams, etc. We should evaluate whether the element makes any sense to keep - in some cases, they do not. We want to talk to the reader, not just introduce some element that already exists. But do keep elements that add value - the reason we have them in the outline is to give some ideas to help us avoid a "wall of text" which is where we've ended up also. We need to find a happy medium ground between "text only" that is difficult to work through, and just introductory sentences added for code blocks, diagrams, and other elements that are added to the diagram to give us something to work with and provide variety.
+
 __review__
 
 We implemented our article by first generating an outline, and then writing each of the sections one by one. Please review the document in its entirety now, and make any suggestions you find that would improve the readability or quality of the article. Do not make any changes - just review and put together a list of suggestions to discuss.