You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Aristedes Maniatis <ar...@maniatis.org> on 2010/05/11 11:08:08 UTC
Supported versions
You'll notice that I tagged the 1.2 release on the site as "archived" that is to imply it is not going to get future updates. Should I close the Jira tasks associated with it and should we send out a formal announcement of the end of life of that version?
Are we advanced enough to have a formal policy of supporting two major versions of Cayenne? If so, something we should put on the web site?
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Cayenne chain-chank problem
Posted by Andrus Adamchik <an...@objectstyle.org>.
Actually looking through Velocity sources, this is expression type-
dependent... E.g. ASTOrNode:
public Object value(InternalContextAdapter context )
throws MethodInvocationException
{
return new Boolean( evaluate( context ) );
}
> Also I suggest that node.jjtGetChild(0).value(context) == null is
> little bit faster then !node.jjtGetChild(0).evaluate(context).
This is not the case in general. See above...
But thinking about it some more, I tend to agree with you on replacing
"evaluate" that returns true/false with "value" that returns an
Object. The purpose of the #chunk directive is documented as "Often it
is desirable to exclude parts of the WHERE clause if some parameters
are null or not set.", so we should be doing NULL checking.
Also since this may be a significant change in behavior and people may
need to rewrite their SQLTemplates, my vote is that it should go to
3.1 only (see this message for a recent discussion on versions http://markmail.org/message/vo6xpzvklye2w5uy
)
Andrus
On May 21, 2010, at 2:52 PM, Рябицкий Евгений wrote:
> This is not how Velocity works... It is how we use it...
> Actually I have already redefined this behavior by changing
> ChunkDirective code.
>
> Change is in one line:
>
> if (node.jjtGetNumChildren() > 1 && !
> node.jjtGetChild(0).evaluate(context)) {
> return false;
> }
>
> To :
>
> if (node.jjtGetNumChildren() > 1 &&
> node.jjtGetChild(0).value(context) == null) {
> return false;
> }
>
>
> I it quite good working and is exactly what I was expecting from
> this case.
>
> Also I suggest that node.jjtGetChild(0).value(context) == null is
> little bit faster then !node.jjtGetChild(0).evaluate(context).
>
> Going to make Jira for it. If there no doubts :)
>
>
>
> Evgeny.
>
>
>
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Friday, May 21, 2010 1:33 PM
> To: dev@cayenne.apache.org
> Subject: Re: Cayenne chain-chank problem
>
> Ok I got it now.
>
> That's how Velocity works. This code is not Cayenne specific. I would
> suggest defining extra variables for conditions, or writing a Velocity
> expression to match your expectations. E.g. "#chunk($id || $id == 0).
> Not sure if you can redefine thsi behavior on the Velocity end.
>
> I am not entirely happy with Velocity as a SQLTemplate engine myself,
> but unless and until we write a substitution, we are stuck with that I
> guess.
>
> Andrus
>
>
> On May 21, 2010, at 12:11 PM, Рябицкий Евгений wrote:
>
>> I took example from http://cayenne.apache.org/doc20/scripting-sqltemplate.html
>> and extend it so it use Boolean fields to show my problem.
>>
>> For me problematic that when I am going to filter ARTISTS with id ==
>> 1 or id == 10 it is all ok I will got query:
>>
>> SELECT * from ARTIST t0 WHERE id = ? [bind: 1 ]
>>
>> But if I am filtering with id == 0 (that is absolute valid column
>> value) I got:
>>
>> SELECT * from ARTIST t0
>>
>> But I was expecting:
>>
>> SELECT * from ARTIST t0 WHERE id = ? [bind: 0 ]
>>
>> That is my problem.... Same for Boolean values, I just want simple
>> filtering by only passed column values.
>>
>>
>> Evgeny.
>>
>>
>>
>> -----Original Message-----
>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> Sent: Friday, May 21, 2010 12:12 PM
>> To: dev@cayenne.apache.org
>> Subject: Re: Cayenne chain-chank problem
>>
>> Hi Evgeny,
>>
>> Where did you find this example?
>>
>> I am checking #chunk directive example here: http://cayenne.apache.org/doc20/scripting-sqltemplate.html
>> and everything seems correct to me. IIRC "0 == null" is how Velocity
>> evaluates expressions (C-style), so this has to be taken into account
>> when building SQLtemplates.
>>
>> So I don't understand which parts you find problematic?
>>
>> Cheers,
>> Andrus
>>
>>
>> On May 21, 2010, at 10:36 AM, Рябицкий Евгений wrote:
>>
>>> Hello, here is example from tutorial for 2.0:
>>>
>>> String sql = "SELECT DISTINCT"
>>> + " #result('ARTIST_ID' 'int'),"
>>> + " #result('ARTIST_NAME' 'String'),"
>>> + " #result('DATE_OF_BIRTH' 'java.util.Date')"
>>> + " #result('IS_DEAD' 'java.util.Boolean')"
>>> + " FROM ARTIST t0"
>>> + " #chain('OR' 'WHERE') // start
>>> chain prefixed by WHERE,
>>> // and joined
>>> by OR
>>> + " #chunk($name) ARTIST_NAME LIKE #bind($name) #end" //
>>> ARTIST_NAMEchunk"
>>> + " #chunk($id) ARTIST_ID > #bind($id) #end" // ARTIST_ID
>>> chunk"
>>> + " #chunk($isDead) IS_DEAD = #bind($isDead) #end" // IS_DEAD
>>> chunk"
>>> + " #end"; // end of
>>> chain
>>> SQLTemplate select = new SQLTemplate(Artist.class, sql, true);
>>>
>>>
>>> If I put in isDead true - everything is ok, but if I put false I got
>>> chat this condition is skipper because #chunk is actually checking
>>> condition of $isDead.
>>>
>>> Same thing if I put 0 in $id it will be false.
>>>
>>> So this example of tutorial is bad for Dead Artists or Artists with
>>> id == 0.
>>> Maybe it's a bug of #chunk directive and it should do only null
>>> check??
>>>
>>> Evgeny.
>>>
>>
>>
>
>
RE: Cayenne chain-chank problem
Posted by Рябицкий Евгений <er...@diasoft.ru>.
This is not how Velocity works... It is how we use it...
Actually I have already redefined this behavior by changing ChunkDirective code.
Change is in one line:
if (node.jjtGetNumChildren() > 1 && !node.jjtGetChild(0).evaluate(context)) {
return false;
}
To :
if (node.jjtGetNumChildren() > 1 && node.jjtGetChild(0).value(context) == null) {
return false;
}
I it quite good working and is exactly what I was expecting from this case.
Also I suggest that node.jjtGetChild(0).value(context) == null is little bit faster then !node.jjtGetChild(0).evaluate(context).
Going to make Jira for it. If there no doubts :)
Evgeny.
-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org]
Sent: Friday, May 21, 2010 1:33 PM
To: dev@cayenne.apache.org
Subject: Re: Cayenne chain-chank problem
Ok I got it now.
That's how Velocity works. This code is not Cayenne specific. I would
suggest defining extra variables for conditions, or writing a Velocity
expression to match your expectations. E.g. "#chunk($id || $id == 0).
Not sure if you can redefine thsi behavior on the Velocity end.
I am not entirely happy with Velocity as a SQLTemplate engine myself,
but unless and until we write a substitution, we are stuck with that I
guess.
Andrus
On May 21, 2010, at 12:11 PM, Рябицкий Евгений wrote:
> I took example from http://cayenne.apache.org/doc20/scripting-sqltemplate.html
> and extend it so it use Boolean fields to show my problem.
>
> For me problematic that when I am going to filter ARTISTS with id ==
> 1 or id == 10 it is all ok I will got query:
>
> SELECT * from ARTIST t0 WHERE id = ? [bind: 1 ]
>
> But if I am filtering with id == 0 (that is absolute valid column
> value) I got:
>
> SELECT * from ARTIST t0
>
> But I was expecting:
>
> SELECT * from ARTIST t0 WHERE id = ? [bind: 0 ]
>
> That is my problem.... Same for Boolean values, I just want simple
> filtering by only passed column values.
>
>
> Evgeny.
>
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Friday, May 21, 2010 12:12 PM
> To: dev@cayenne.apache.org
> Subject: Re: Cayenne chain-chank problem
>
> Hi Evgeny,
>
> Where did you find this example?
>
> I am checking #chunk directive example here: http://cayenne.apache.org/doc20/scripting-sqltemplate.html
> and everything seems correct to me. IIRC "0 == null" is how Velocity
> evaluates expressions (C-style), so this has to be taken into account
> when building SQLtemplates.
>
> So I don't understand which parts you find problematic?
>
> Cheers,
> Andrus
>
>
> On May 21, 2010, at 10:36 AM, Рябицкий Евгений wrote:
>
>> Hello, here is example from tutorial for 2.0:
>>
>> String sql = "SELECT DISTINCT"
>> + " #result('ARTIST_ID' 'int'),"
>> + " #result('ARTIST_NAME' 'String'),"
>> + " #result('DATE_OF_BIRTH' 'java.util.Date')"
>> + " #result('IS_DEAD' 'java.util.Boolean')"
>> + " FROM ARTIST t0"
>> + " #chain('OR' 'WHERE') // start
>> chain prefixed by WHERE,
>> // and joined
>> by OR
>> + " #chunk($name) ARTIST_NAME LIKE #bind($name) #end" //
>> ARTIST_NAMEchunk"
>> + " #chunk($id) ARTIST_ID > #bind($id) #end" // ARTIST_ID
>> chunk"
>> + " #chunk($isDead) IS_DEAD = #bind($isDead) #end" // IS_DEAD
>> chunk"
>> + " #end"; // end of chain
>> SQLTemplate select = new SQLTemplate(Artist.class, sql, true);
>>
>>
>> If I put in isDead true - everything is ok, but if I put false I got
>> chat this condition is skipper because #chunk is actually checking
>> condition of $isDead.
>>
>> Same thing if I put 0 in $id it will be false.
>>
>> So this example of tutorial is bad for Dead Artists or Artists with
>> id == 0.
>> Maybe it's a bug of #chunk directive and it should do only null
>> check??
>>
>> Evgeny.
>>
>
>
Re: Cayenne chain-chank problem
Posted by Andrus Adamchik <an...@objectstyle.org>.
Ok I got it now.
That's how Velocity works. This code is not Cayenne specific. I would
suggest defining extra variables for conditions, or writing a Velocity
expression to match your expectations. E.g. "#chunk($id || $id == 0).
Not sure if you can redefine thsi behavior on the Velocity end.
I am not entirely happy with Velocity as a SQLTemplate engine myself,
but unless and until we write a substitution, we are stuck with that I
guess.
Andrus
On May 21, 2010, at 12:11 PM, Рябицкий Евгений wrote:
> I took example from http://cayenne.apache.org/doc20/scripting-sqltemplate.html
> and extend it so it use Boolean fields to show my problem.
>
> For me problematic that when I am going to filter ARTISTS with id ==
> 1 or id == 10 it is all ok I will got query:
>
> SELECT * from ARTIST t0 WHERE id = ? [bind: 1 ]
>
> But if I am filtering with id == 0 (that is absolute valid column
> value) I got:
>
> SELECT * from ARTIST t0
>
> But I was expecting:
>
> SELECT * from ARTIST t0 WHERE id = ? [bind: 0 ]
>
> That is my problem.... Same for Boolean values, I just want simple
> filtering by only passed column values.
>
>
> Evgeny.
>
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Friday, May 21, 2010 12:12 PM
> To: dev@cayenne.apache.org
> Subject: Re: Cayenne chain-chank problem
>
> Hi Evgeny,
>
> Where did you find this example?
>
> I am checking #chunk directive example here: http://cayenne.apache.org/doc20/scripting-sqltemplate.html
> and everything seems correct to me. IIRC "0 == null" is how Velocity
> evaluates expressions (C-style), so this has to be taken into account
> when building SQLtemplates.
>
> So I don't understand which parts you find problematic?
>
> Cheers,
> Andrus
>
>
> On May 21, 2010, at 10:36 AM, Рябицкий Евгений wrote:
>
>> Hello, here is example from tutorial for 2.0:
>>
>> String sql = "SELECT DISTINCT"
>> + " #result('ARTIST_ID' 'int'),"
>> + " #result('ARTIST_NAME' 'String'),"
>> + " #result('DATE_OF_BIRTH' 'java.util.Date')"
>> + " #result('IS_DEAD' 'java.util.Boolean')"
>> + " FROM ARTIST t0"
>> + " #chain('OR' 'WHERE') // start
>> chain prefixed by WHERE,
>> // and joined
>> by OR
>> + " #chunk($name) ARTIST_NAME LIKE #bind($name) #end" //
>> ARTIST_NAMEchunk"
>> + " #chunk($id) ARTIST_ID > #bind($id) #end" // ARTIST_ID
>> chunk"
>> + " #chunk($isDead) IS_DEAD = #bind($isDead) #end" // IS_DEAD
>> chunk"
>> + " #end"; // end of chain
>> SQLTemplate select = new SQLTemplate(Artist.class, sql, true);
>>
>>
>> If I put in isDead true - everything is ok, but if I put false I got
>> chat this condition is skipper because #chunk is actually checking
>> condition of $isDead.
>>
>> Same thing if I put 0 in $id it will be false.
>>
>> So this example of tutorial is bad for Dead Artists or Artists with
>> id == 0.
>> Maybe it's a bug of #chunk directive and it should do only null
>> check??
>>
>> Evgeny.
>>
>
>
RE: Cayenne chain-chank problem
Posted by Рябицкий Евгений <er...@diasoft.ru>.
I took example from http://cayenne.apache.org/doc20/scripting-sqltemplate.html and extend it so it use Boolean fields to show my problem.
For me problematic that when I am going to filter ARTISTS with id == 1 or id == 10 it is all ok I will got query:
SELECT * from ARTIST t0 WHERE id = ? [bind: 1 ]
But if I am filtering with id == 0 (that is absolute valid column value) I got:
SELECT * from ARTIST t0
But I was expecting:
SELECT * from ARTIST t0 WHERE id = ? [bind: 0 ]
That is my problem.... Same for Boolean values, I just want simple filtering by only passed column values.
Evgeny.
-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org]
Sent: Friday, May 21, 2010 12:12 PM
To: dev@cayenne.apache.org
Subject: Re: Cayenne chain-chank problem
Hi Evgeny,
Where did you find this example?
I am checking #chunk directive example here: http://cayenne.apache.org/doc20/scripting-sqltemplate.html
and everything seems correct to me. IIRC "0 == null" is how Velocity
evaluates expressions (C-style), so this has to be taken into account
when building SQLtemplates.
So I don't understand which parts you find problematic?
Cheers,
Andrus
On May 21, 2010, at 10:36 AM, Рябицкий Евгений wrote:
> Hello, here is example from tutorial for 2.0:
>
> String sql = "SELECT DISTINCT"
> + " #result('ARTIST_ID' 'int'),"
> + " #result('ARTIST_NAME' 'String'),"
> + " #result('DATE_OF_BIRTH' 'java.util.Date')"
> + " #result('IS_DEAD' 'java.util.Boolean')"
> + " FROM ARTIST t0"
> + " #chain('OR' 'WHERE') // start
> chain prefixed by WHERE,
> // and joined
> by OR
> + " #chunk($name) ARTIST_NAME LIKE #bind($name) #end" //
> ARTIST_NAMEchunk"
> + " #chunk($id) ARTIST_ID > #bind($id) #end" // ARTIST_ID
> chunk"
> + " #chunk($isDead) IS_DEAD = #bind($isDead) #end" // IS_DEAD
> chunk"
> + " #end"; // end of chain
> SQLTemplate select = new SQLTemplate(Artist.class, sql, true);
>
>
> If I put in isDead true - everything is ok, but if I put false I got
> chat this condition is skipper because #chunk is actually checking
> condition of $isDead.
>
> Same thing if I put 0 in $id it will be false.
>
> So this example of tutorial is bad for Dead Artists or Artists with
> id == 0.
> Maybe it's a bug of #chunk directive and it should do only null
> check??
>
> Evgeny.
>
Re: Cayenne chain-chank problem
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Evgeny,
Where did you find this example?
I am checking #chunk directive example here: http://cayenne.apache.org/doc20/scripting-sqltemplate.html
and everything seems correct to me. IIRC "0 == null" is how Velocity
evaluates expressions (C-style), so this has to be taken into account
when building SQLtemplates.
So I don't understand which parts you find problematic?
Cheers,
Andrus
On May 21, 2010, at 10:36 AM, Рябицкий Евгений wrote:
> Hello, here is example from tutorial for 2.0:
>
> String sql = "SELECT DISTINCT"
> + " #result('ARTIST_ID' 'int'),"
> + " #result('ARTIST_NAME' 'String'),"
> + " #result('DATE_OF_BIRTH' 'java.util.Date')"
> + " #result('IS_DEAD' 'java.util.Boolean')"
> + " FROM ARTIST t0"
> + " #chain('OR' 'WHERE') // start
> chain prefixed by WHERE,
> // and joined
> by OR
> + " #chunk($name) ARTIST_NAME LIKE #bind($name) #end" //
> ARTIST_NAMEchunk"
> + " #chunk($id) ARTIST_ID > #bind($id) #end" // ARTIST_ID
> chunk"
> + " #chunk($isDead) IS_DEAD = #bind($isDead) #end" // IS_DEAD
> chunk"
> + " #end"; // end of chain
> SQLTemplate select = new SQLTemplate(Artist.class, sql, true);
>
>
> If I put in isDead true - everything is ok, but if I put false I got
> chat this condition is skipper because #chunk is actually checking
> condition of $isDead.
>
> Same thing if I put 0 in $id it will be false.
>
> So this example of tutorial is bad for Dead Artists or Artists with
> id == 0.
> Maybe it's a bug of #chunk directive and it should do only null
> check??
>
> Evgeny.
>
Cayenne chain-chank problem
Posted by Рябицкий Евгений <er...@diasoft.ru>.
Hello, here is example from tutorial for 2.0:
String sql = "SELECT DISTINCT"
+ " #result('ARTIST_ID' 'int'),"
+ " #result('ARTIST_NAME' 'String'),"
+ " #result('DATE_OF_BIRTH' 'java.util.Date')"
+ " #result('IS_DEAD' 'java.util.Boolean')"
+ " FROM ARTIST t0"
+ " #chain('OR' 'WHERE') // start chain prefixed by WHERE,
// and joined by OR
+ " #chunk($name) ARTIST_NAME LIKE #bind($name) #end" //ARTIST_NAMEchunk"
+ " #chunk($id) ARTIST_ID > #bind($id) #end" // ARTIST_ID chunk"
+ " #chunk($isDead) IS_DEAD = #bind($isDead) #end" // IS_DEAD chunk"
+ " #end"; // end of chain
SQLTemplate select = new SQLTemplate(Artist.class, sql, true);
If I put in isDead true - everything is ok, but if I put false I got chat this condition is skipper because #chunk is actually checking condition of $isDead.
Same thing if I put 0 in $id it will be false.
So this example of tutorial is bad for Dead Artists or Artists with id == 0.
Maybe it's a bug of #chunk directive and it should do only null check??
Evgeny.
Re: Supported versions
Posted by Malcolm Edgar <ma...@gmail.com>.
+1
On Thu, May 20, 2010 at 7:00 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>> Are we advanced enough to have a formal policy of supporting two major
>>> versions of Cayenne? If so, something we should put on the web site?
>
> Absolutely. I think we do need a clear road map and a page on the website
> (not on wiki) listing what releases we support and what is the sunset date
> for the oldest of those. When closing the Jiras against discontinued
> releases, we need to make sure they do not affect newer releases, otherwise
> such jiras simply need to be rescheduled.
>
> Now the question of what we put on that road map. here are my thoughts:
>
> 1. Now: I think that while 1.2 and 2.0 are the same thing, it helps if we
> announce now that we stopped supporting 1.2. 1.2 adds to the effort of
> preparing a release, as it is done from SourceForge infrastructure. So lets
> encourage the upgrade.
>
> 2. Nearest future: I'd also like to discontinue support for 2.0.x at some
> point (maybe after we have a 3.0.1 maintenance out). The upgrade path to 3.0
> is rather trivial, so I don't see why we should keep it around. Also the new
> 3.1 doesn't support upgrade from 2.0, only from 3.0, so this is yet another
> reason to encourage people to upgrade now to avoid pain in the future.
>
> Evgeny, you committed a bunch of fixes to the 2.0 branch, so maybe you can
> give us your point of view on that. I am open to anything, including making
> a 2.0.5 before announcing 2.0.x sunset, or keeping it around longer, but if
> we have no good reasons to expect a 2.0.6, I'd rather we encourage our users
> to upgrade to 3.0.
>
> Andrus
>
>
> On May 11, 2010, at 2:17 PM, Michael Gentry wrote:
>>
>> 1.2 and 2.0 are the same release, though. Just different package spaces.
>>
>>
>> On May 11, 2010, at 5:08 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>
>>> You'll notice that I tagged the 1.2 release on the site as "archived"
>>> that is to imply it is not going to get future updates. Should I close the
>>> Jira tasks associated with it and should we send out a formal announcement
>>> of the end of life of that version?
>>>
>>> Are we advanced enough to have a formal policy of supporting two major
>>> versions of Cayenne? If so, something we should put on the web site?
>>>
>>> Ari
>>>
>>>
>>> --
>>> -------------------------->
>>> Aristedes Maniatis
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>
>
Re: Supported versions
Posted by Andrus Adamchik <an...@objectstyle.org>.
>> Are we advanced enough to have a formal policy of supporting two
>> major versions of Cayenne? If so, something we should put on the
>> web site?
Absolutely. I think we do need a clear road map and a page on the
website (not on wiki) listing what releases we support and what is the
sunset date for the oldest of those. When closing the Jiras against
discontinued releases, we need to make sure they do not affect newer
releases, otherwise such jiras simply need to be rescheduled.
Now the question of what we put on that road map. here are my thoughts:
1. Now: I think that while 1.2 and 2.0 are the same thing, it helps if
we announce now that we stopped supporting 1.2. 1.2 adds to the effort
of preparing a release, as it is done from SourceForge infrastructure.
So lets encourage the upgrade.
2. Nearest future: I'd also like to discontinue support for 2.0.x at
some point (maybe after we have a 3.0.1 maintenance out). The upgrade
path to 3.0 is rather trivial, so I don't see why we should keep it
around. Also the new 3.1 doesn't support upgrade from 2.0, only from
3.0, so this is yet another reason to encourage people to upgrade now
to avoid pain in the future.
Evgeny, you committed a bunch of fixes to the 2.0 branch, so maybe you
can give us your point of view on that. I am open to anything,
including making a 2.0.5 before announcing 2.0.x sunset, or keeping it
around longer, but if we have no good reasons to expect a 2.0.6, I'd
rather we encourage our users to upgrade to 3.0.
Andrus
On May 11, 2010, at 2:17 PM, Michael Gentry wrote:
> 1.2 and 2.0 are the same release, though. Just different package
> spaces.
>
>
> On May 11, 2010, at 5:08 AM, Aristedes Maniatis <ar...@maniatis.org>
> wrote:
>
>> You'll notice that I tagged the 1.2 release on the site as
>> "archived" that is to imply it is not going to get future updates.
>> Should I close the Jira tasks associated with it and should we send
>> out a formal announcement of the end of life of that version?
>>
>> Are we advanced enough to have a formal policy of supporting two
>> major versions of Cayenne? If so, something we should put on the
>> web site?
>>
>> Ari
>>
>>
>> --
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
Re: Supported versions
Posted by Michael Gentry <mg...@masslight.net>.
1.2 and 2.0 are the same release, though. Just different package spaces.
On May 11, 2010, at 5:08 AM, Aristedes Maniatis <ar...@maniatis.org>
wrote:
> You'll notice that I tagged the 1.2 release on the site as
> "archived" that is to imply it is not going to get future updates.
> Should I close the Jira tasks associated with it and should we send
> out a formal announcement of the end of life of that version?
>
> Are we advanced enough to have a formal policy of supporting two
> major versions of Cayenne? If so, something we should put on the web
> site?
>
> Ari
>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A