>It has to be possible to eventually retire old code. I think we all >agreed that we won't retire HFile V1 in 0.94.
I agree, I just don't think you should deprecate for the sake of doing it. There are quarantining methods to get rarely-used code out of the way and minimize interference. Let's talk about an explicit strategy for that. I would rather there be some innocuous deprecated code that's present for a year longer than it's needed, but no one notices. I think HFile upgrade in particular is more complicated than you think. We currently have production traffic running with HFileV1. It has a 5-min SLA. We can't afford to take the entire downtime to rewrite 100GB (or whatever) worth of data. We need to do this while the cluster is live. >It is essential for any successful software product to retire old cruft >at some point or we'll be in backwards compatibility hell. Matt already >voiced concerns for his trie prefix compression feature. Is it OK to only >support that for v2? I think there's a difference between supporting an deprecated feature and enhancing it. You shouldn't need to support compression for V1. You should just support the functionality that was present in the past. I would ask Matt to work with Mikhail, who is also doing prefix compression for V2.
