<?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: Release management in open source projects</title>
	<atom:link href="http://osswatch.jiscinvolve.org/wp/2009/12/02/release-management-in-open-source-projects/feed/" rel="self" type="application/rss+xml" />
	<link>http://osswatch.jiscinvolve.org/wp/2009/12/02/release-management-in-open-source-projects/</link>
	<description>open source software innovation support centre</description>
	<lastBuildDate>Fri, 03 Feb 2012 15:30:22 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ross Gardler</title>
		<link>http://osswatch.jiscinvolve.org/wp/2009/12/02/release-management-in-open-source-projects/comment-page-1/#comment-246</link>
		<dc:creator>Ross Gardler</dc:creator>
		<pubDate>Fri, 11 Dec 2009 12:11:07 +0000</pubDate>
		<guid isPermaLink="false">http://osswatch.jiscinvolve.org/2009/12/02/release-management-in-open-source-projects/#comment-246</guid>
		<description>I totally agree Bertrand, and I&#039;m pleased to say the software Sander is talking about here has a reasonably complete test suite. We are running a continuous integration server at http://16degrees.com.au/hudson

Our tests even check license headers in source files.</description>
		<content:encoded><![CDATA[<p>I totally agree Bertrand, and I&#8217;m pleased to say the software Sander is talking about here has a reasonably complete test suite. We are running a continuous integration server at <a href="http://16degrees.com.au/hudson" rel="nofollow" onclick="javascript:urchinTracker ('/outbound/comment/16degrees.com.au');">http://16degrees.com.au/hudson</a></p>
<p>Our tests even check license headers in source files.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Links 05/12/2009: KDE Software Compilation 4.4 (“Kompilation”) in Beta &#124; Boycott Novell</title>
		<link>http://osswatch.jiscinvolve.org/wp/2009/12/02/release-management-in-open-source-projects/comment-page-1/#comment-245</link>
		<dc:creator>Links 05/12/2009: KDE Software Compilation 4.4 (“Kompilation”) in Beta &#124; Boycott Novell</dc:creator>
		<pubDate>Sun, 06 Dec 2009 04:16:35 +0000</pubDate>
		<guid isPermaLink="false">http://osswatch.jiscinvolve.org/2009/12/02/release-management-in-open-source-projects/#comment-245</guid>
		<description>[...] Release management in open source projects Whatever release management process you choose, the dynamic nature of many projects makes it valuable to adjust the process to your needs and for instance choose a mix of the two discussed methods. [...]</description>
		<content:encoded><![CDATA[<p>[...] Release management in open source projects Whatever release management process you choose, the dynamic nature of many projects makes it valuable to adjust the process to your needs and for instance choose a mix of the two discussed methods. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bertrand Delacretaz</title>
		<link>http://osswatch.jiscinvolve.org/wp/2009/12/02/release-management-in-open-source-projects/comment-page-1/#comment-244</link>
		<dc:creator>Bertrand Delacretaz</dc:creator>
		<pubDate>Thu, 03 Dec 2009 16:40:06 +0000</pubDate>
		<guid isPermaLink="false">http://osswatch.jiscinvolve.org/2009/12/02/release-management-in-open-source-projects/#comment-244</guid>
		<description>Depending on the type of software that you&#039;re producing, automated tests make all the difference in terms of release management.

If your automated (unit and integration) tests are good enough, you&#039;re basically ready to make a release any time all tests pass.

That&#039;s of course easier to achieve for infrastructure software and libraries, as opposed to software with complex visual user interfaces. But even there, having a clear split between a non-visual core (where tests are easier to automate) and the graphical parts can help tremendously, by minimizing the amount of manual testing.</description>
		<content:encoded><![CDATA[<p>Depending on the type of software that you&#8217;re producing, automated tests make all the difference in terms of release management.</p>
<p>If your automated (unit and integration) tests are good enough, you&#8217;re basically ready to make a release any time all tests pass.</p>
<p>That&#8217;s of course easier to achieve for infrastructure software and libraries, as opposed to software with complex visual user interfaces. But even there, having a clear split between a non-visual core (where tests are easier to automate) and the graphical parts can help tremendously, by minimizing the amount of manual testing.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

