On Fri, May 18, 2012 at 1:19 AM, César Álvarez Núñez <cesar.alvarez.nu...@gmail.com> wrote: > Hi Patrick, > > I thoroughly agree with your opinion. > > When you say "major version upgrade", you mean an increase on the 2nd digit > (for example from 3.4.X to 3.5.X) or the first digit?
The format is major.minor.fix (so 4.x.x would be the next major). The last time we did a major was when we joined Apache. (2008?) Major upgrades are very disruptive for users, so we've been reticent to do so. Rather we favor making changes in a backward compatible way, I don't see any way to do that here... > Anyway, is it correct to create a Jira ticket and provide a patch although > it would not be committed until the next major version upgrade? That's perfectly fine, although it's likely to hang around for a while (ie fix version 4.0.0). There are a number of API changes that we've discussed in the past that are similarly slated. (ie changing the version from 32bit to 64, etc...) Patrick > /César. > > On Thu, May 17, 2012 at 11:41 PM, Patrick Hunt <ph...@apache.org> wrote: > >> On Thu, May 17, 2012 at 2:21 AM, César Álvarez Núñez >> <cesar.alvarez.nu...@gmail.com> wrote: >> > Hi All, >> > >> > When I create a node with null data, Stat.dataLength is 0. >> > When I create a node with byte[0] data, Stat.dataLength is 0. >> > >> > I think that in the first case dataLength should return -1 instead of 0. >> > >> > Which is your opinion? I will create a ticket and try to fix it if you >> > agree. >> >> The current API is such that we treat the length of a null and an >> empty string both as 0. Regardless, what you are suggesting would >> change the api in a non-backward compatible way, not something we >> consider outside of a major version upgrade. >> >> Patrick >>
