On 5 Feb 2009, at 15:56, Brian Stansberry wrote:
Manik Surtani wrote:
> Not JBC 3.1.0 with NBST? Even though NBST is new and relatively
> unproven, it can be disabled in the default cfg.
> There are a number of important bug fixes in 3.1.0 that you will
> probably want. If you really don't want 3.1.0, I could cut 3.0.3
> with the said fixes, which are:
>
http://tinyurl.com/brg35m
I see 4 of 47 issues resolved for 3.1.0. :)
I need to revise that roadmap. We decided to cut 3.1.0 with the 4 bug
fixes and NBST, push the rest out to 3.2.0. :)
https://jira.jboss.org/jira/browse/JBCACHE/fixforversion/12311895
One of the things I want to get out of AS moving to release-early-
release-often is getting out of the cycle of trying to cram in
component upgrades.
That said, I'd of course like to see non-blocking-state-transfer in
AS 5.1. But I don't want to try and cram it in -- needs to be highly
stable and in a highly stable release ready well ahead of time. To
me clustering in 5.1 is about profile service and embedded console
stuff.
This is why I suggested that by default NBST could be disabled. But
your call either way, reckon you want a 3.0.3 then?
> On 4 Feb 2009, at 20:31, Brian Stansberry wrote:
>> JBC 3.0.2.GA (there now)
>> POJO Cache 3.0.1.GA -- if you release one ;)
>> JGroups 2.6.8
>> ha-server-cache-spi & ha-server-cache-jbc -- perhaps 2.0.0, but
>> not really a big change there
>>
>> Jason T. Greene wrote:
>>> Project Leads,
>>> The next planned AS release is 5.1 Beta which we are targeting
>>> for a March release, and a following GA in April (provided no
>>> major problems).
>>> I need to know what versions of your respective components you
>>> would like included in this release. These would preferably be of
>>> CR or better quality, although a beta release may be OK if you
>>> are confident you can get a GA shortly thereafter. It would also
>>> be helpful if you could limit the scope of whatever version you
>>> are targeting for AS inclusion to be the features that benefit AS.
>>> Keep in mind that we are transitioning to a frequent release
>>> cycle for the AS, so there is no need to rush your project to
>>> make this release. The more stable the project releases are, the
>>> less time it takes getting the AS ready to release.
>>> Thanks!
>>
>>
>> --
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-development
> --
> Manik Surtani
> Lead, JBoss Cache
>
http://www.jbosscache.org
> manik(a)jboss.org <mailto:manik@jboss.org>
> ------------------------------------------------------------------------
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik(a)jboss.org