Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Thu, 12 May 2011 16:47:47 +0000 (UTC)
From: "Alexander Shorin (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <1837464793.7239.1305218867444.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <163403437.7238.1305218867403.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (COUCHDB-1164) Pass CouchDB version to view server
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/COUCHDB-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Shorin updated COUCHDB-1164:
--------------------------------------

    Priority: Minor  (was: Major)

> Pass CouchDB version to view server
> -----------------------------------
>
>                 Key: COUCHDB-1164
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1164
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: JavaScript View Server
>            Reporter: Alexander Shorin
>            Priority: Minor
>
> Imagine that I'm developer of some view server. I'd like to create view server which covers most of CouchDB releases. Each new CouchDB release brings new features, improvements and API changes, some times backward-incompatible (as for 0.9->0.10->0.11->0.11.1) . However, I couldn't solve this task due to there is not way to know about CouchDB version and API that I have to implement. So there are three ways that I have:
> 1. develop only "bleeding edge" view server that support only latest version
> 2. make separate branch per version
> 3. keep "all in one" and pass version as command line argument.
> First one makes to forgot about old releases, second is supporting hell. Last one is more effective, but requires to keep in mind changing argument on server update.
> So there is actually no way to make great view server such as javascript/erlang one with "wide" CouchDB versions support. Without that support using and developing couchapps for ruby/python/clojure/others view servers is quite unpromising.
> This issue could be an improvement of COUCHDB-904 by using next scenario:
> CouchDB pass "version" command to view server with additional value of CouchDB version and excepts that view server return his version back. That would be something like "version exchange". 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira