JRedis 1.0 RC 1 announce

>
> Issue Reporting:
>
> Please report any issues or feature requests for final 1.0 release
> here:http://github.com/alphazero/jredis/issues
>
> Thank you.
>
> /enjoy

Wouldn't it be easier for users to follow the Redis versioning?
Basically, a (possible) user would know immediately if the version is
meant for Redis 1.2.x or the upcoming Redis 2.x. You could use the
minor version for library versioning.

:- alex

Joubin Houshyar

unread,

Mar 22, 2010, 7:57:24 AM3/22/10

to Redis DB

On Mar 22, 6:17 am, Alex Popescu <the.mindstorm.mailingl...@gmail.com>
wrote:

Well, I did leave the issue up for discussion for a few days :)
Project is still in its early stages and nothing is set in stone.

Other than that, I'm looking at potential *significant* changes to the
interfaces and RI internals to address the changes in Redis since
1.2.n. So, there'll probably be a stretch when there is a version
supporting 1.3.n (minus MULTI/EXEC/DISCARD) that does not break the
existing JRedis[Future] interfaces [say 1.3], and, a version which
will support the stateful/transactional semantics and commands and
will break existing user code [2.0]. Both will be 1.3.n, but will be
different, and most likely require patches as well. So how would you
use a <redis-major.redis-minor.jredis-version> scheme to address that?

I've also considered a non-standard <major.minor.patch>-
<redis.compliance> scheme, but am not sure if that is yet another can
of worms.

Basically, as of now, I'm going by the assumption that there will
always be only 1 official Redis release (e.g. 1.2.n) and a Redis
development edge in GitHub. And JRedis will also be released in
<M.m.p> versions for the official release and the alpha.0 version will
be the one tracking Redis "unstable'.

>
> :- alex

/R

Alex Popescu

unread,

Mar 23, 2010, 6:37:30 PM3/23/10

to Redis DB

On Mar 22, 1:57 pm, Joubin Houshyar <suno...@gmail.com> wrote:
> On Mar 22, 6:17 am, Alex Popescu <the.mindstorm.mailingl...@gmail.com>
> wrote:
>
>
>
>
>
> > On Mar 21, 11:41 pm, Joubin Houshyar <suno...@gmail.com> wrote:
>

> > >JRedis1.0 RC1 [Redis 1.2.n compliance] announce:

>
> > > Release Notes:http://github.com/alphazero/jredis/blob/1.2.n/Release/RELEASE-NOTES-1...
>
> > > Release client lib (binary only):http://github.com/downloads/alphazero/jredis/jredis-1.0-rc1.jar
>
> > > Release Project Archives:http://github.com/alphazero/jredis/tarball/JRedis-1.0-RC1[tarball]http://github.com/alphazero/jredis/zipball/JRedis-1.0-RC1[zip]
>
> > > GitHub:
> > > * Release is tagged as 'JRedis-1.0-RC1' in github.
> > > * Branch is 1.2.n
> > > * commits range:
> > > begin:http://github.com/alphazero/jredis/commit/d7a775c795dd5ae7ef70e0f7144...
> > > end: http://github.com/alphazero/jredis/commit/e562fb4d9df4b1ec4b9f2d9ba56...
>
> > > Issue Reporting:
>
> > > Please report any issues or feature requests for final 1.0 release
> > > here:http://github.com/alphazero/jredis/issues
>
> > > Thank you.
>
> > > /enjoy
>
> > Wouldn't it be easier for users to follow the Redis versioning?
> > Basically, a (possible) user would know immediately if the version is
> > meant for Redis 1.2.x or the upcoming Redis 2.x. You could use the
> > minor version for library versioning.
>
> Well, I did leave the issue up for discussion for a few days :)
> Project is still in its early stages and nothing is set in stone.
>
> Other than that, I'm looking at potential *significant* changes to the
> interfaces and RI internals to address the changes in Redis since
> 1.2.n. So, there'll probably be a stretch when there is a version
> supporting 1.3.n (minus MULTI/EXEC/DISCARD) that does not break the

> existingJRedis[Future] interfaces [say 1.3], and, a version which

> will support the stateful/transactional semantics and commands and
> will break existing user code [2.0]. Both will be 1.3.n, but will be
> different, and most likely require patches as well. So how would you
> use a <redis-major.redis-minor.jredis-version> scheme to address that?
>
> I've also considered a non-standard <major.minor.patch>-
> <redis.compliance> scheme, but am not sure if that is yet another can
> of worms.
>
> Basically, as of now, I'm going by the assumption that there will
> always be only 1 official Redis release (e.g. 1.2.n) and a Redis

> development edge in GitHub. AndJRediswill also be released in

> <M.m.p> versions for the official release and the alpha.0 version will
> be the one tracking Redis "unstable'.
>

Well, I think that you can go with redis-major.redis-minor.jredis-
version-jredis-patch-version and that will address some of the
scenarios you've described.

Personally, I've always hated the situations where I had to hunt for a
library version to fit another project version. While I don't think
there are any silver bullet approaches, it does seem that Redis is
going is normal major.minor.patch approach and so you wouldn't expect
API/protocol changes on patch level that allowing jredis to also use
jredis-version.jredis-patch.

Speaking of which, I was wondering if jredis supports unencoded keys
(f.e. 'a key')?

:- alex
>
>
> > :- alex
>
> /R

Joubin Houshyar

unread,

Mar 23, 2010, 7:42:55 PM3/23/10

to Redis DB

Hi Alex,

On Mar 23, 6:37 pm, Alex Popescu <the.mindstorm.mailingl...@gmail.com>

Right, but since its none standard, it will be meaningless to the
users that can't be bothered with reading release docs ;) Alternative
we can just put a matrix up on the project page for downloads and nail
it that way.

>
> Personally, I've always hated the situations where I had to hunt for a
> library version to fit another project version.

I hear you. That's why I asked.

> While I don't think
> there are any silver bullet approaches, it does seem that Redis is
> going is normal major.minor.patch approach and so you wouldn't expect
> API/protocol changes on patch level that allowing jredis to also use
> jredis-version.jredis-patch.

Theoretically. Redis is not just a blazingly fast DB. Its also a
fast moving target:

Here is a transition from 1.1 to 1.2.n.

http://github.com/alphazero/jredis/commit/385c7d2044b2414e5361ff6eb4ed52ff51546c16

The API changed.

>
> Speaking of which, I was wondering if jredis supports unencoded keys
> (f.e. 'a key')?

Right now 1.0 RC1 supports the multi bulk protocol for 'String' type r/
w commands. Its not a big deal to mod the api for MSET//MGET to take
byte[] for keys, instead of Strings. I actually don't know if 1.2.5
supports multi bulk protocol for all commands, but lets say it does:
its a lot of grunt work to make that happen and frankly it'll take a
lot of user clamoring for that to pop to the top of the todo list,
given that sharding and full 1.3.n compliance are also in that list.
If all you need is embedded spaces in your *string* keys, I can have
add a transform f() to do that transparently and give high prob
guarantees that it won't collide with other keys (e.g. map ' ' to
'___' or any other configurable non-whitespace sequence). (This will
break client interop but that doesn't seem to be an issue.)

But if you want full binary key support, then I need some measure of
user consensus to motivate me to make it happen :)

>
> :- alex

/R

Joubin Houshyar

unread,

Mar 26, 2010, 11:26:15 AM3/26/10

to Redis DB

JRedis 1.0 RC1 has been updated for full compliance w/ Redis 1.2.6.

Information below remains accurate, with noted GitHub changes:

* commit range:
end: http://github.com/alphazero/jredis/commit/6e46cfa009ee1f23100cc98441c41bfa4f2c8ae0

Issue Reporting:

Please report any issues or feature requests for final 1.0 release
here:
http://github.com/alphazero/jredis/issues

Thank you.

/enjoy

On Mar 21, 5:41 pm, Joubin Houshyar <suno...@gmail.com> wrote:
> JRedis 1.0 RC1 [Redis 1.2.n compliance] announce:
>

> Release Notes:http://github.com/alphazero/jredis/blob/1.2.n/Release/RELEASE-NOTES-1...

>
> Release client lib (binary only):http://github.com/downloads/alphazero/jredis/jredis-1.0-rc1.jar
>
> Release Project Archives:http://github.com/alphazero/jredis/tarball/JRedis-1.0-RC1[tarball]http://github.com/alphazero/jredis/zipball/JRedis-1.0-RC1[zip]
>
> GitHub:
> * Release is tagged as 'JRedis-1.0-RC1' in github.
> * Branch is 1.2.n
> * commits range:

> begin:http://github.com/alphazero/jredis/commit/d7a775c795dd5ae7ef70e0f7144...
> end: http://github.com/alphazero/jredis/commit/e562fb4d9df4b1ec4b9f2d9ba56...

Reply all

Reply to author

Forward