You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Damien Katz <da...@gmail.com> on 2008/04/15 17:05:08 UTC
couch 0.8.0 release
Storage compaction and mochiweb are now checked in. We need to think
about getting the next release done.
What should the criteria be for the next release? Here are some of my
thoughts:
If we plan any significant interface changes in HTTP, javascript, etc,
they should be done by 0.8.0. The longer we wait to make interface
changes, the more apps and libraries we break and the less likely it
will ever get done.
We need to have an upgrade utility and instructions for going from 0.7
to 0.8
Bugs and client compatibility problems with mochiweb are okay for
0.8.0 As problems crop up, we'll fix them and release patches.
The database internals should not have known bugs, but this is still
alpha software. I think we need to make it clearer on the site,
download pages, readme, etc that CouchDB isn't reliable yet. For
example, CouchDB isn't an acid database on OSX (maybe all BSDs), but
is on Linux, because of platform specific flags etc. These are
problems that will be fixed before shipping, but for now might cause a
lot of pain.
Re: couch 0.8.0 release
Posted by Jan Lehnardt <ja...@apache.org>.
Heya Damien,
On Apr 15, 2008, at 17:05, Damien Katz wrote:
> Storage compaction and mochiweb are now checked in. We need to think
> about getting the next release done.
+1
> What should the criteria be for the next release? Here are some of
> my thoughts:
>
> If we plan any significant interface changes in HTTP, javascript,
> etc, they should be done by 0.8.0. The longer we wait to make
> interface changes, the more apps and libraries we break and the less
> likely it will ever get done.
This sounds very sensible. What possible changes are we looking at?
Here's what I could think of off the cuff:
- HTTP API for triggering and monitoring compaction
- Fulltext Search
- attachment handling
We have at least plannend changes for each of those. Anything else?
> We need to have an upgrade utility and instructions for going from
> 0.7 to 0.8
For the future we probably want to have a utility that we can use
manage upgrades, so we could try and make one now, that we can reuse
for further updates or we just write something together that works for
now and deal with a more general approach later.
> Bugs and client compatibility problems with mochiweb are okay for
> 0.8.0 As problems crop up, we'll fix them and release patches.
>
> The database internals should not have known bugs, but this is still
> alpha software. I think we need to make it clearer on the site,
> download pages, readme, etc that CouchDB isn't reliable yet. For
> example, CouchDB isn't an acid database on OSX (maybe all BSDs), but
> is on Linux, because of platform specific flags etc. These are
> problems that will be fixed before shipping, but for now might cause
> a lot of pain.
We should probably open documentation bugs for these things. Any takers?
One more thing: Christopher Lenz will be on holiday until mid-may and
I suggest holding off at least until then, since he had a great chunk
in the current changes, so his timely response to problem reports
might be desirable.
Cheers
Jan
--
Re: couch 0.8.0 release
Posted by Christopher Lenz <cm...@gmx.de>.
On 15.04.2008, at 17:05, Damien Katz wrote:
> Storage compaction and mochiweb are now checked in. We need to think
> about getting the next release done.
>
> What should the criteria be for the next release? Here are some of
> my thoughts:
>
> If we plan any significant interface changes in HTTP, javascript,
> etc, they should be done by 0.8.0. The longer we wait to make
> interface changes, the more apps and libraries we break and the less
> likely it will ever get done.
In the backwards-incompatible changes department, here's what I think
would be nice to get into 0.8:
* RESTful attachments API: Use DELETE/PUT for attachment manipulation;
maybe provide a multipart interface for uploads, and for retrieving
the JSON doc with all attachments (in addition too--or even instead
of--the current inlining into the JSON)
* Decide on the JSON API to use and stick with it; switching libs will
break DB files. It'd probably be best to use mochijson.erl or
mochison2.erl, as those come with MochiWeb and are included in our
codebase anyway, and we'd get rid of the patched up cjson.erl, making
updating from upstream easier.
* Not sure, but implementing reduce/combine functionality will
probably cause a change to the database form, right? If we agree to
"wait" about a month for the release, is reduce realistically
implementable for 0.8? ;)
> We need to have an upgrade utility and instructions for going from
> 0.7 to 0.8
Right, very important.
I've added rudimentary dump/load scripts to my couchdb-python library,
available here:
<http://code.google.com/p/couchdb-python/source/browse/trunk/couchdb/tools/
>
* dump.py takes a database URL and writes all the documents it
contains to stdout using a MIME multipart format.
* load.py takes the URL of an empty target database, and reads
documents from stdin, using the same multipart format.
Those don't support attachments yet, and the process should probably
use the same HTTP API used by replication (think "offline
replication"). In any case, the multipart format works pretty well,
and I suggest we adopt it when we add a built-in dump/load interface.
You can nest multipart envelopes (for attachments), and there's no
need to load the complete file into memory and parse it into a JSON
object tree (and vice versa).
> Bugs and client compatibility problems with mochiweb are okay for
> 0.8.0 As problems crop up, we'll fix them and release patches.
I think we should get the test suite to reliably succeed under Safari,
which is the only current problem I'm aware of. If the suite fails
(intermittently even) on a fresh official release, that's not such a
good first impression.
> The database internals should not have known bugs, but this is still
> alpha software. I think we need to make it clearer on the site,
> download pages, readme, etc that CouchDB isn't reliable yet. For
> example, CouchDB isn't an acid database on OSX (maybe all BSDs), but
> is on Linux, because of platform specific flags etc. These are
> problems that will be fixed before shipping, but for now might cause
> a lot of pain.
Yeah, the alpha status needs to be made more obvious. On a somewhat
related note, some of the docs also need to be reviewed and changed so
that it's clearer which features work right now, and which features
are incomplete or only planned for the future (search, reduce/combine,
authn/authz/validation, etc).
As Jan mentioned (and I said on IRC), I'll be on vacation and mostly
offline for the next 3 weeks. I've been lucky to get a lot of code
into CouchDB in the last couple of weeks (SpiderMonkey, MochiWeb, many
Futon enhancements), so I'd also really like to be involved when we
package things up and subsequently need to support the release by
answering questions, helping to troubleshoot problems, and fixing bugs
(and throwing the virtual release party ;) ). And of course there's
still a number of formal things that need to be sorted out before we
can make our first release out of the Incubator. So I'd be in favor of
targetting a 0.8 release in mid May.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: couch 0.8.0 release
Posted by Jan Lehnardt <ja...@prima.de>.
Heya Matt.
On Apr 15, 2008, at 18:05, Matt Goodall wrote:
> On 15/04/2008, Jan Lehnardt <ja...@apache.org> wrote:
>> On Apr 15, 2008, at 17:36, Matt Goodall wrote:
>>
>>> There was a change to the db update notification protocol (sorry,
>>> can't remember the name of the config option right now). Are any
>>> further changes expected?
>>>
>>
>> DbUpdateNotificationProcess is the name of that option, I don't
>> think there
>> were any changes, though.
>
> You're probably right but I the line that CouchDB sends to the update
> notification process used to be just the name of a database. The line
> now contains a simple JSON object with "type" and "db" attributes.
Nope, you are correct. That did change and it might change in the
future, but in a backward compatible way by extending the JSON object.
> Unfortunately, the svn history was lost with the move to the ASF so I
> can't check.
The Google Code should still have the history.
Cheers
Jan
Re: couch 0.8.0 release
Posted by Matt Goodall <ma...@gmail.com>.
On 15/04/2008, Jan Lehnardt <ja...@apache.org> wrote:
> On Apr 15, 2008, at 17:36, Matt Goodall wrote:
>
> > There was a change to the db update notification protocol (sorry,
> > can't remember the name of the config option right now). Are any
> > further changes expected?
> >
>
> DbUpdateNotificationProcess is the name of that option, I don't think there
> were any changes, though.
You're probably right but I the line that CouchDB sends to the update
notification process used to be just the name of a database. The line
now contains a simple JSON object with "type" and "db" attributes.
Unfortunately, the svn history was lost with the move to the ASF so I
can't check.
Not that it really matters ;-).
- Matt
Re: couch 0.8.0 release
Posted by Jan Lehnardt <ja...@apache.org>.
On Apr 15, 2008, at 17:36, Matt Goodall wrote:
> On 15/04/2008, Damien Katz <da...@gmail.com> wrote:
>> Storage compaction and mochiweb are now checked in. We need to
>> think about
>> getting the next release done.
>>
>> What should the criteria be for the next release? Here are some of my
>> thoughts:
>>
>> If we plan any significant interface changes in HTTP, javascript,
>> etc, they
>> should be done by 0.8.0. The longer we wait to make interface
>> changes, the
>> more apps and libraries we break and the less likely it will ever
>> get done.
>
> There was some discussion about adding a more REST-ful attachment API.
> Is that likely to go ahead still?
My understanding is that we still want that and now that we switched
to MochiWeb, it is actually feasible to work on it.
> There was a change to the db update notification protocol (sorry,
> can't remember the name of the config option right now). Are any
> further changes expected?
DbUpdateNotificationProcess is the name of that option, I don't think
there were any changes, though.
> Does the view API need any changes to support full text indexing?
The way that is t me the most sensible way to make that happen would
require changes in CouchDB that are very likely not to go into 0.8.
This would not change, but rather extend the view API so things should
be backwards compatible (but maybe don't take my word for it, since we
are still in discussions :) . Until then, indexers need to work around
some of the limitations here, but can be simplified when CouchDB nears
1.0.
Thanks for your input, Matt,
Jan
--
Re: couch 0.8.0 release
Posted by Matt Goodall <ma...@gmail.com>.
On 15/04/2008, Damien Katz <da...@gmail.com> wrote:
> Storage compaction and mochiweb are now checked in. We need to think about
> getting the next release done.
>
> What should the criteria be for the next release? Here are some of my
> thoughts:
>
> If we plan any significant interface changes in HTTP, javascript, etc, they
> should be done by 0.8.0. The longer we wait to make interface changes, the
> more apps and libraries we break and the less likely it will ever get done.
There was some discussion about adding a more REST-ful attachment API.
Is that likely to go ahead still?
There was a change to the db update notification protocol (sorry,
can't remember the name of the config option right now). Are any
further changes expected?
Does the view API need any changes to support full text indexing?
Personally, I like the simplicity of the current design but I noticed
(but haven't had chance to read) some lengthy discussions on the
subject.
- Matt