Re: Question on updating Cassandra dependencies
Wow. It would be great if the Jackson dep could move up to 2.x. We'd even be willing to provide a PR for it. On Fri, Mar 13, 2015 at 12:22 PM, Joe Fasano wrote: > Hello All, > > I have been told by my team that some of the cassandra dependencies have > some vulnerabilities and > should be upgraded. Specifically, > Joda Time 1.6 should be upgraded to 2.7 > Jackson 1.9.2 should be upgraded to 1.9.13 > > Is there any schedule or process of getting Cassandra updates to include > updated dependencies? > > > Thanks, > joe > > > Joe Fasano > Sr. Development Manager > Symantec Corporation > > >
Re: Time for 1.0
+1.0 I'm not a committer, but I think a 1.0 is warranted, especially given the number of folks who have the application in production. (In fact, 0.7 would have made a reasonable 1.0.) -- Paul On Jan 11, 2011, at 5:35 PM, Jonathan Ellis wrote: > Way back in Nov 09, we did a users survey and asked what features > people wanted to see. Here was my summary of the responses: > http://www.mail-archive.com/cassandra-user@incubator.apache.org/msg01446.html > > Looking at that, we've done essentially all of them. I think we can > make a strong case that our next release should be 1.0; it's > production ready, it's reasonably feature-complete, it's documented, > and we know what our upgrade path story is. > > The list-- > > Load balancing: basics done; > https://issues.apache.org/jira/browse/CASSANDRA-1427 is open to > improve it > > Decommission: done > > Map/reduce support: done > > ColumnFamily / Keyspace definitions w/o restart: done > > Design documentation: started at > http://wiki.apache.org/cassandra/ArchitectureInternals > > Insert multiple rows at once: done > > Remove_slice_range / remove_key_range: turned out to be a *lot* harder > than it looks at first. Postponed indefinitely. > > Secondary indexing: done > > Caching: done (with some enhancements possible such as > https://issues.apache.org/jira/browse/CASSANDRA-1969 and > https://issues.apache.org/jira/browse/CASSANDRA-1956) > > Bulk delete (truncate): done > > I would add, > > User documentation: done (http://www.riptano.com/docs) > > Large row support: done > > Improved replication strategies and more sophisticated ConsistencyLevels: done > > Efficient bootstrap/streaming: done > > Flow control: done > > Network-level compatibility between releases: scheduled > (https://issues.apache.org/jira/browse/CASSANDRA-1015) > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com
Re: Reducing confusion around client libraries
On Dec 3, 2010, at 12:13 PM, Eric Evans wrote: > On Fri, 2010-12-03 at 13:46 -0600, Tyler Hobbs wrote: >> Personally, I like the Mongo drivers page: >> http://www.mongodb.org/display/DOCS/Drivers >> >> I like the clear distinction between preferred and alternative clients >> without a lot of clutter about release dates and supported versions. >> How do we make that distinction, though? A "supported by Riptano" >> section is one option, but that doesn't even encompass all of the >> preferred clients. > This sounds like you're suggesting that we place an "official according > to Riptano" section on the project wiki. That sounds... worse. The PMC can sort it out, but I don't think it's within the purview/charter of the project to bless third-party libraries. For libraries/content that are shipped with officially Apache artifacts, there are clear and specific standards in terms of licenses, intellectual property, etc., and endorsing (versus simply listing) third-party components on a project site is probably inappropriate. (IMHO.) What happens on a third party's site is another matter. -- Paul
Re: Reducing confusion around client libraries
On Dec 3, 2010, at 11:54 AM, Jonathan Ellis wrote: >> Or a vendor who wanted Cassandra-related traffic could post a client >> registry backed by a simple database... > :) > Backing it with a database doesn't solve the evaluation problem, though. At the point you back it with a database, you can add a few social features like "I'm using this" or "Like" and have a reasonable collaborative filter... Cheers. -- Paul
Re: Reducing confusion around client libraries
On Dec 3, 2010, at 9:43 AM, Jonathan Ellis wrote: > The status quo is not working. There are way too many questions on > the user list and on irc about problems with writing Thrift code, even > when well-maintained clients exist for their language of choice. And > that's just the users who were motivated enough to ask instead of > tweeting that thrift sucks and giving up. [...] This problem isn't unique to Cassandra. It cropped up, e.g., in managing the proliferation of Haskell libraries on Hackage. One way that this could be accomplished with a relatively even hand is to ensure that the relative liveliness of the client libraries is apparent on the page, e.g., a most recent release date, the target language (and potentially any additional decoration like Spring or Rails or...), and a list of versions of Cassandra supported. The onus is on the client library maintainer to properly advertise their wares by updating the entry on the page, and making it sortable/searchable would be a win. (There are some rumblings about MoinMoin (http://moinmo.in/FeatureRequests/SortableTables) being able to do this, and there is also something like a Google Spreadsheet as an option. Or a vendor who wanted Cassandra-related traffic could post a client registry backed by a simple database... -- Paul
