<?xml version="1.0" encoding="utf-8"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><language>en</language><title>Blog posts by Per Ivansson</title> <link>https://world.optimizely.com/blogs/Per-Ivansson/</link><description></description><ttl>60</ttl><generator>Optimizely World</generator><item> <title>EPiServer Release Cycle Terminology</title>            <link>https://world.optimizely.com/blogs/Per-Ivansson/Dates/2011/4/EPiServer-Release-Cycle-Terminology/</link>            <description>&lt;p&gt;This post aims to clarify the terminology used for different stages in the release cycle of EPiServer products, the purpose and what can be expected in terms of feature completeness, upgrade paths and support. It also aims to answer the question : “What can I start to develop on?”.&lt;/p&gt;  &lt;p&gt;&lt;b&gt;CTP&lt;/b&gt; (Community Technology Preview)&lt;/p&gt;  &lt;p&gt;A CTP release is the first stage of the release cycle with the main purpose to get early. CTPs releases can either be closed and targeted to a selected focus group or open to the public. CTP releases are not feature complete, has no supported, or even guaranteed possible,&amp;#160; upgrade paths to RTM. We strongly advice against using CTP releases as a starting point for projects aiming for production.&lt;/p&gt;  &lt;p&gt;&lt;b&gt;Beta&lt;/b&gt;&lt;/p&gt;  &lt;p&gt;A Beta release is the second stage of the release cycle and the main purpose is still to get feedback on functionality but also to receive bug reports. Beta releases can be open or closed. Beta releases may not be feature complete but should have the main features in place. We generally describe breaking changes and upgrade paths to RTM but upgrade paths to RTM are not supported. Using Beta releases in projects aiming for production is not recommended but can at your own responsibility be a starting point for your project as the changes are often minor and in most cases documented to enable a manual upgrade to RTM.&lt;/p&gt;  &lt;p&gt;&lt;b&gt;RC&lt;/b&gt; (Release Candidate)&lt;/p&gt;  &lt;p&gt;A RC release is the third stage of the release cycle and is generally feature complete and the main purpose is to get late feedback and bug reports. RC releases can be open or closed. No breaking changes are expected at this stage and upgrade paths to RTM are described and in most cases automated. RC releases and upgrade paths are however not supported and using RC releases in projects aiming for production is still on your own responsibility but upgrade to RTM should be fairly straightforward even though it might involve manual steps. &lt;/p&gt;  &lt;p&gt;&lt;b&gt;RTM&lt;/b&gt; (Release to Marketing)&lt;/p&gt;  &lt;p&gt;A RTM release is the finalized product with full support.&lt;/p&gt;  &lt;p&gt;&lt;b&gt;GA&lt;/b&gt; (General Available)&lt;/p&gt;  &lt;p&gt;GA is the publically available RTM release.&lt;/p&gt;  &lt;p&gt;Note: Any intermediate builds between Beta to RC or RC to RTM, no matter how they are obtained, are not supported and have no supported or documented upgrade paths to RTM.&lt;/p&gt;</description>            <guid>https://world.optimizely.com/blogs/Per-Ivansson/Dates/2011/4/EPiServer-Release-Cycle-Terminology/</guid>            <pubDate>Tue, 12 Apr 2011 21:00:57 GMT</pubDate>           <category>Blog post</category></item><item> <title>Security Vulnerability in ASP.NET</title>            <link>https://world.optimizely.com/blogs/Per-Ivansson/Dates/2010/9/Security-Vulnerability-in-ASPNET/</link>            <description>&lt;p&gt;Last week on Wednesday the 15th, EPiServer was alerted of a security vulnerability in Microsoft ASP.NET. We also learned that the details would be made publically available on a security conference in Argentina by two researchers on Friday later that week. Due to the indicated seriousness of the vulnerability, we made the investigation of this our top priority within the development department and on Thursday we could confirm that the exploit really existed as described. The vulnerability is in the ASP.NET encryption mechanism and parts of the exploit lie in how error messages are returned by the .NET Framework. &lt;/p&gt;  &lt;p&gt;We acted according to our set processes in a situation as this and communicated with the main contacts at our partners so that they received relevant information about the matter. This was done well before the public announcement was made at the conference. EPiServer’s proposed workaround was more or less identical to the one announced by Microsoft later Friday evening, but with some additions. For more information regarding the vulnerability and the workaround, please read: &lt;/p&gt;  &lt;p&gt;&lt;a href=&quot;http://www.microsoft.com/technet/security/advisory/2416728.mspx&quot;&gt;http://www.microsoft.com/technet/security/advisory/2416728.mspx&lt;/a&gt;&lt;/p&gt;  &lt;p&gt;&lt;a title=&quot;http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx&quot; href=&quot;http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx&quot;&gt;http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx&lt;/a&gt;&lt;/p&gt;  &lt;p&gt;We advice everyone to take this threat very seriously and act accordingly.&lt;/p&gt;</description>            <guid>https://world.optimizely.com/blogs/Per-Ivansson/Dates/2010/9/Security-Vulnerability-in-ASPNET/</guid>            <pubDate>Mon, 20 Sep 2010 10:28:46 GMT</pubDate>           <category>Blog post</category></item><item> <title>Migrating EPiServer Community 3.1 to 3.2</title>            <link>https://world.optimizely.com/blogs/Per-Ivansson/Dates/2009/3/Migrating-EPiServer-Community-31-to-32/</link>            <description>&lt;p&gt;At last, the promised migration scripts and documentation is available here:&lt;/p&gt; &lt;p&gt;&lt;a href=&quot;http://world.episerver.com/en/Articles/Items/Migrating-StarCommunity-31-to-EPiServer-Community-32/&quot;&gt;http://world.episerver.com/en/Articles/Items/Migrating-StarCommunity-31-to-EPiServer-Community-32/&lt;/a&gt;&lt;/p&gt;</description>            <guid>https://world.optimizely.com/blogs/Per-Ivansson/Dates/2009/3/Migrating-EPiServer-Community-31-to-32/</guid>            <pubDate>Thu, 19 Mar 2009 20:16:26 GMT</pubDate>           <category>Blog post</category></item><item> <title>Distributed Memory Caching in EPiServer Community using Velocity</title>            <link>https://world.optimizely.com/blogs/Per-Ivansson/Dates/2008/10/Distributed-Memory-Caching-in-EPiServer-Community-using-Velocity/</link>            <description>&lt;p&gt;It&#180;s the last day of PDC2008 and I&#39;ve been to a lot of sessions by now. The Cloud is everywhere... One session I really think stood out was the one about the Velocity project. We have looked on Velocity, Memcached and other similar distributed memory caching systems for a while now as one comparatively low investment to improve performance and scalability of EPiServer Community. One benefit of having a distributed &quot;central&quot; cache instead of, or in addition to, having local caches on each web server is that it reduces database calls when the cache is invalidated and needs to re-populate from persisted data.&lt;/p&gt; &lt;p&gt;For example: Say that you have five web servers in your cluster. When a cache is invalidated, it propagates throughout the cluster and one separate call from each web server has to made to the database to populate the local cache again. That is five roundtrips to the database to retrieve the exact same data. The more web servers in this setup, the higher the load on the database server. With a distributed cache, the distributed cache would populate itself from the persisted data only once, and concurrent requests from the web servers would use that cache instead of query the database themselves.&lt;/p&gt; &lt;p&gt;Velocity have some nice features beyond the basics. For example: It&#39;s fully scalable. You may just add machines as you go along as the sync between them is handled automatically. You can configure consistency vs availability of data by defining number of fail over nodes etc.. Another cool thing is that it supports tagging of cached data so that you retrieve collections of cached objects by their tagging. Even cooler is that is supports Linq, so you can actually write queries that filter and returns data directly from the cache. Everything can of course operate in that Cloud of theirs... &lt;/p&gt; &lt;p&gt;A fully scalable cache repository that you can query using Linq, opens quite interesting possibilities for high transactional applications such as EPiServer Community and we will surely look into this in the very near future. The current state of Velocity is CTP2. CTP3 will be released Q1 2009 and the first release is expected Q2/Q3 2009.&lt;/p&gt;</description>            <guid>https://world.optimizely.com/blogs/Per-Ivansson/Dates/2008/10/Distributed-Memory-Caching-in-EPiServer-Community-using-Velocity/</guid>            <pubDate>Thu, 30 Oct 2008 19:00:08 GMT</pubDate>           <category>Blog post</category></item></channel>
</rss>