<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Deploying patches in your Flex application</title>
	<atom:link href="http://flexblog.faratasystems.com/2007/12/24/deploying-patches-in-your-flex-application/feed" rel="self" type="application/rss+xml" />
	<link>http://flexblog.faratasystems.com/2007/12/24/deploying-patches-in-your-flex-application</link>
	<description>A blog about our experience with Adobe Flex</description>
	<lastBuildDate>Tue, 31 Jan 2012 19:52:28 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Yakov Fain</title>
		<link>http://flexblog.faratasystems.com/2007/12/24/deploying-patches-in-your-flex-application/comment-page-1#comment-34714</link>
		<dc:creator>Yakov Fain</dc:creator>
		<pubDate>Wed, 02 Jan 2008 10:58:13 +0000</pubDate>
		<guid isPermaLink="false">http://flexblog.faratasystems.com/?p=279#comment-34714</guid>
		<description>A patch is a patch. It&#039;s a temp solution between scheduled releases. Many enterprises have pretty strict and formal release procedures, and releasing just one patches.swc, even if it has a bunch of classes, can be a viable solution. Italso  may be easier to approve an emergency release that consists of replacing just one file patches.swc with another one.

Needless to say that you are implementing the same changes in the original classes located where they&#039;re supposed to be, and on the next scheduled release you empty patches.swc.</description>
		<content:encoded><![CDATA[<p>A patch is a patch. It&#8217;s a temp solution between scheduled releases. Many enterprises have pretty strict and formal release procedures, and releasing just one patches.swc, even if it has a bunch of classes, can be a viable solution. Italso  may be easier to approve an emergency release that consists of replacing just one file patches.swc with another one.</p>
<p>Needless to say that you are implementing the same changes in the original classes located where they&#8217;re supposed to be, and on the next scheduled release you empty patches.swc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: barry.b</title>
		<link>http://flexblog.faratasystems.com/2007/12/24/deploying-patches-in-your-flex-application/comment-page-1#comment-34685</link>
		<dc:creator>barry.b</dc:creator>
		<pubDate>Wed, 02 Jan 2008 00:11:36 +0000</pubDate>
		<guid isPermaLink="false">http://flexblog.faratasystems.com/?p=279#comment-34685</guid>
		<description>I can see how that works fine for small changes, but what about changes that have dependencies? where you&#039;re needing to update a bunch of classes that are from different parts of an application (eg a new minor feature that adds UI, processing, code from different parts of the application, etc). I can just see that lumping all that into a &quot;patches&quot; swc may be a bridge too far.

thoughts?</description>
		<content:encoded><![CDATA[<p>I can see how that works fine for small changes, but what about changes that have dependencies? where you&#8217;re needing to update a bunch of classes that are from different parts of an application (eg a new minor feature that adds UI, processing, code from different parts of the application, etc). I can just see that lumping all that into a &#8220;patches&#8221; swc may be a bridge too far.</p>
<p>thoughts?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

