Rodrigo Moya [2010-05-26 8:56 -0000]:
> So, if we are not allowed to do on-disk format changes, this means
> we need to freeze the format used in Karmic for years
Well, isn't that the point of stable releases?
> and not improve / evolve it at all.
We did not say that, though. The problem is right now that the way we
use couchdb now does not provide any kind of versioning. If there was
a version field which client apps could check, and which would be
bumped on format changes, it would at least be possible for client
apps to handle underlying format changes. Right now it's not possible
at all, and if you mix different couchdb sources from different
releases/sources/etc. you'd just create a mess. As long as this point
does not get addressed, I do not want to accept such kind of
unversioned on-disk format changes as an SRU. Once there is proper
support for versioning, this can be revisited, of course.
Rodrigo Moya [2010-05-26 8:56 -0000]:
> So, if we are not allowed to do on-disk format changes, this means
> we need to freeze the format used in Karmic for years
Well, isn't that the point of stable releases?
> and not improve / evolve it at all.
We did not say that, though. The problem is right now that the way we sources/ etc. you'd just create a mess. As long as this point
use couchdb now does not provide any kind of versioning. If there was
a version field which client apps could check, and which would be
bumped on format changes, it would at least be possible for client
apps to handle underlying format changes. Right now it's not possible
at all, and if you mix different couchdb sources from different
releases/
does not get addressed, I do not want to accept such kind of
unversioned on-disk format changes as an SRU. Once there is proper
support for versioning, this can be revisited, of course.