couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: [4/6] git commit: Fix copy-paste typo, remove changes history for request object.
Date Mon, 03 Dec 2012 01:09:42 GMT
On Mon, Dec 3, 2012 at 4:29 AM, Noah Slater <nslater@apache.org> wrote:
> Actually, Alexander. I think I stick by my original point. Even though we
> talked about only tracking information for 1.3 and onwards, doesn't it seem
> a bit silly to remove information that we already have?

I wouldn't protect this changes, but there should be clear policy: to
track history of all things or to track not it. If there exists
history about changes of Request object, probably we have to se tup
others too. If we have decided to track history since some point, it
should be base point to start counting from. The only matters question
"how deeper" I need to go for this history: for base objects and http
API I have drafts with changes tracks, it's not problem to undo revert
and add others. Just tell me that and I'll do it since I'm not sure
what really need to do.

> I guess I'm confused about what the purpose of this information is for. If
> this is the sort of thing that you'd actually want to know about as an end
> user. Say, you've just installed the latest and greatest, and you want to
> have things called out, then that makes sense. It would also be good to
> know what has been depreciated or depreciated. What else is this
> information good for?

This information helps to quick overview history of changes for older
releases without need to lookup their docs and/or reading their change
logs. While this information is special targeted for some
feature/object it's clearly may give answer about backward
compatibility. Say, I'd found `since=now` parameter support for
_changes feed in 1.3.0, but looks like it doesn't exists in older
releases => I need to care about workaround ways if I need to support
older CouchDB releases while using same feature. It's the best for
client developers and simplifies their life since they have to support
as much versions as it possible. Yes, there is global article "What's
new in 1.3.0" that describes all changes within single release, but
when you implementing some feature you'd like to see all possible
information about it at single page without noise.

--
,,,^..^,,,

Mime
View raw message