[redis.git] / doc / RedisStatus.html


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
    <head>
        <link type="text/css" rel="stylesheet" href="style.css" />
    </head>
    <body>
        <div id="page">
        
            <div id='header'>
            <a href="index.html">
            <img style="border:none" alt="Redis Documentation" src="redis.png">
            </a>
            </div>
        
            <div id="pagecontent">
                <div class="index">
<!-- This is a (PRE) block.  Make sure it's left aligned or your toc title will be off. -->
<b>RedisStatus: Contents</b><br>&nbsp;&nbsp;<a href="#Redis Status Page">Redis Status Page</a><br>&nbsp;&nbsp;<a href="#How stable are the alpha previews?">How stable are the alpha previews?</a><br>&nbsp;&nbsp;<a href="#How to obtain a 2.2-alpha preview">How to obtain a 2.2-alpha preview</a><br>&nbsp;&nbsp;<a href="#ETA for Redis 2.2?">ETA for Redis 2.2?</a><br>&nbsp;&nbsp;<a href="#When will we be able to see a working version of Redis Cluster?">When will we be able to see a working version of Redis Cluster?</a>
                </div>
                
                <h1 class="wikiname">RedisStatus</h1>

                <div class="summary">
                    
                </div>

                <div class="narrow">
                    <h1><a name="Redis Status Page">Redis Status Page</a></h1>Hello! Redis uses versions composed of three numbers separated by a dot: <b>major</b>.<b>minor</b>.<b>patchlevel</b>.<br/><br/>When the <b>minor</b> is an odd number, it is used for an unstable release, so stable releases are for instance 1.2, 2.0, and so forth.<br/><br/>This is the status of the different Redis versions currently available:<br/><br/><ul><li> 1.2 is the <b>legacy redis stable release</b>, now it is completely obsoleted by Redis 2.0. Redis 2.0 is almost completely back compatible with 1.2 so upgrading is usually not a problem. Still 1.2 is believed to be a very stable release that works well, so if you are using it in production with code that probably will not modified to use more advanced Redis features available in 2.0, it makes sense to take 1.2 running. For everything new, it's better to start with 2.0.</li></ul>
<ul><li> 2.0 is the current <b>stable release</b>. It is better than 1.2 in more or less everything: more features, more mature code, better replication, better persistence, and so forth. It is currently what most users should use, unless they really need features that are only available into an <b>unstable</b> release.</li></ul>
<ul><li> 2.1 is the current <b>unstable release</b>, and there are no tar.gz for this release, you need to download it from git. <b>Warning:</b> the master branch in git may work most of the time but is NOT what you should use. What's better instead is to use the 2.2-alpha tags: every time Redis 2.1.x is stable enough and the new features merged passed all the tests for a couple of weeks, and we didn't received severe bug reports from users, we tag master as 2.2-alpha <i>number</i>, where <i>number</i> is simply a progressive number. Just pick this number.</li></ul>
<h1><a name="How stable are the alpha previews?">How stable are the alpha previews?</a></h1>
Well it is surely ok for development, but it is not recommended for production. Still there are many users that trust Redis development process so much to use alpha releases in production, but this is up to you, we don't give any guarantee ;)<h1><a name="How to obtain a 2.2-alpha preview">How to obtain a 2.2-alpha preview</a></h1>Simply using git:
<pre class="codeblock python" name="code">
$ git clone git://github.com/antirez/redis.git
Initialized empty Git repository in /tmp/redis/.git/
...
</pre>
Then you can list all the branches matching 2.1-alpha with:
<pre class="codeblock python python" name="code">
cd redis
$ git tag | grep 2.2-alpha
2.2-alpha0
2.2-alpha1
2.2-alpha2
</pre>
At this point you can just use <b>git checkout <i>tagname</i></b>, substituting <i>tagname</i> with 2.2-alphaX where X is the greater progressive number you see in the listing.<h1><a name="ETA for Redis 2.2?">ETA for Redis 2.2?</a></h1>
Redis 2.2 is planned to enter the release candidate stage before the end of the 2010.<h1><a name="When will we be able to see a working version of Redis Cluster?">When will we be able to see a working version of Redis Cluster?</a></h1>
I'm already working at it, I mean not just designing, but writing code. In three months we should have some kind of experimental version, while in six months we should have the first release candidate.<br/><br/>Probably the first <b>stable</b> release of Redis with working cluster will be called 3.0, but I'll try to merge it into 2.2 as an experimental support if we'll be sure there is no impact in the stability of the system when clustering is not used.
                </div>
        
            </div>
        </div>
    </body>
</html>
Commit	Line	Data
6674e3b9	1
	2	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
	3	<html>
	4	<head>
	5	<link type="text/css" rel="stylesheet" href="style.css" />
	6	</head>
	7	<body>
	8	<div id="page">
	9
	10	<div id='header'>
	11	<a href="index.html">
	12	<img style="border:none" alt="Redis Documentation" src="redis.png">
	13	</a>
	14	</div>
	15
	16	<div id="pagecontent">
	17	<div class="index">
	18	<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
	19	<b>RedisStatus: Contents</b><br>  <a href="#Redis Status Page">Redis Status Page</a><br>  <a href="#How stable are the alpha previews?">How stable are the alpha previews?</a><br>  <a href="#How to obtain a 2.2-alpha preview">How to obtain a 2.2-alpha preview</a><br>  <a href="#ETA for Redis 2.2?">ETA for Redis 2.2?</a><br>  <a href="#When will we be able to see a working version of Redis Cluster?">When will we be able to see a working version of Redis Cluster?</a>
	20	</div>
	21
	22	<h1 class="wikiname">RedisStatus</h1>
	23
	24	<div class="summary">
	25
	26	</div>
	27
	28	<div class="narrow">
	29	<h1><a name="Redis Status Page">Redis Status Page</a></h1>Hello! Redis uses versions composed of three numbers separated by a dot: <b>major</b>.<b>minor</b>.<b>patchlevel</b>.<br/><br/>When the <b>minor</b> is an odd number, it is used for an unstable release, so stable releases are for instance 1.2, 2.0, and so forth.<br/><br/>This is the status of the different Redis versions currently available:<br/><br/><ul><li> 1.2 is the <b>legacy redis stable release</b>, now it is completely obsoleted by Redis 2.0. Redis 2.0 is almost completely back compatible with 1.2 so upgrading is usually not a problem. Still 1.2 is believed to be a very stable release that works well, so if you are using it in production with code that probably will not modified to use more advanced Redis features available in 2.0, it makes sense to take 1.2 running. For everything new, it's better to start with 2.0.</li></ul>
	30	<ul><li> 2.0 is the current <b>stable release</b>. It is better than 1.2 in more or less everything: more features, more mature code, better replication, better persistence, and so forth. It is currently what most users should use, unless they really need features that are only available into an <b>unstable</b> release.</li></ul>
	31	<ul><li> 2.1 is the current <b>unstable release</b>, and there are no tar.gz for this release, you need to download it from git. <b>Warning:</b> the master branch in git may work most of the time but is NOT what you should use. What's better instead is to use the 2.2-alpha tags: every time Redis 2.1.x is stable enough and the new features merged passed all the tests for a couple of weeks, and we didn't received severe bug reports from users, we tag master as 2.2-alpha <i>number</i>, where <i>number</i> is simply a progressive number. Just pick this number.</li></ul>
	32	<h1><a name="How stable are the alpha previews?">How stable are the alpha previews?</a></h1>
	33	Well it is surely ok for development, but it is not recommended for production. Still there are many users that trust Redis development process so much to use alpha releases in production, but this is up to you, we don't give any guarantee ;)<h1><a name="How to obtain a 2.2-alpha preview">How to obtain a 2.2-alpha preview</a></h1>Simply using git:
	34	<pre class="codeblock python" name="code">
	35	$ git clone git://github.com/antirez/redis.git
	36	Initialized empty Git repository in /tmp/redis/.git/
	37	...
	38	</pre>
	39	Then you can list all the branches matching 2.1-alpha with:
	40	<pre class="codeblock python python" name="code">
	41	cd redis
	42	$ git tag \| grep 2.2-alpha
	43	2.2-alpha0
	44	2.2-alpha1
	45	2.2-alpha2
	46	</pre>
	47	At this point you can just use <b>git checkout <i>tagname</i></b>, substituting <i>tagname</i> with 2.2-alphaX where X is the greater progressive number you see in the listing.<h1><a name="ETA for Redis 2.2?">ETA for Redis 2.2?</a></h1>
	48	Redis 2.2 is planned to enter the release candidate stage before the end of the 2010.<h1><a name="When will we be able to see a working version of Redis Cluster?">When will we be able to see a working version of Redis Cluster?</a></h1>
	49	I'm already working at it, I mean not just designing, but writing code. In three months we should have some kind of experimental version, while in six months we should have the first release candidate.<br/><br/>Probably the first <b>stable</b> release of Redis with working cluster will be called 3.0, but I'll try to merge it into 2.2 as an experimental support if we'll be sure there is no impact in the stability of the system when clustering is not used.
	50	</div>
	51
	52	</div>
	53	</div>
	54	</body>
	55	</html>
	56