From axis-c-dev-return-13121-apmail-ws-axis-c-dev-archive=ws.apache.org@ws.apache.org Mon Feb 12 23:30:31 2007 Return-Path: Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org Received: (qmail 10244 invoked from network); 12 Feb 2007 23:30:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Feb 2007 23:30:30 -0000 Received: (qmail 10150 invoked by uid 500); 12 Feb 2007 23:30:38 -0000 Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org Received: (qmail 10006 invoked by uid 500); 12 Feb 2007 23:30:37 -0000 Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: "Apache AXIS C Developers List" Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list axis-c-dev@ws.apache.org Received: (qmail 9995 invoked by uid 99); 12 Feb 2007 23:30:37 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Feb 2007 15:30:37 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [24.71.223.10] (HELO pd4mo2so.prod.shaw.ca) (24.71.223.10) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Feb 2007 15:30:23 -0800 Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JDD00FSDIIUBGD0@l-daemon> for axis-c-dev@ws.apache.org; Mon, 12 Feb 2007 16:28:06 -0700 (MST) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd3mr3so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JDD00LHKIISQD91@pd3mr3so.prod.shaw.ca> for axis-c-dev@ws.apache.org; Mon, 12 Feb 2007 16:28:06 -0700 (MST) Received: from [192.168.0.103] ([24.69.76.33]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JDD00GG2IIRCV60@l-daemon> for axis-c-dev@ws.apache.org; Mon, 12 Feb 2007 16:28:04 -0700 (MST) Date: Mon, 12 Feb 2007 15:27:45 -0800 From: Chris Darroch Subject: Re: [Axis2] Time for 1.0 Release In-reply-to: <45C6FE1E.6060409@wso2.com> To: Apache AXIS C Developers List Message-id: <45D0F7F1.6030704@pearsoncmg.com> Organization: Pearson CTG/CMG MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-ca, en-us X-Enigmail-Version: 0.93.0.0 References: <45C6C83F.4@wso2.com> <87ejp5yqnr.fsf@etch.wso2.com> <45C6FE1E.6060409@wso2.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060423 X-Virus-Checked: Checked by ClamAV on apache.org Samisa Abeysinghe wrote: > So I would like to propose that we release 1.0 with current set of > features and look to stabilize the current code base before we release > 1.0 as much as possible. > I think we should be able to do this release in one months time. I fear I'm rather swamped in work for the next few months, but I hope to review the codebase before the 1.0 release. I do have a related issue, though, that I think is worth discussing before such a release, and that's what the versioning scheme and rules should be for the project. I'd think these need to be nailed down more or less in stone prior to a 1.x or 1.x.x major release. Users should understand what kinds of guarantees are being made with regard to future compatibility, since we expect them to develop third-party service modules. They should certainly not have to rewrite or recompile these modules if they upgrade their Axis2/C installation to pick up a security bug fix, for example. So, with what versions is it acceptable for Axis2/C to break compatibility with previous versions? How should the versioning scheme indicate such transitions? What about patch releases to fix security bugs; can these change the API or ABI at all? And so forth. As a C project, I would suggest that it might make sense for Axis2/C to follow the lead of other major Apache C projects, such as APR and httpd. These two have fairly detailed versioning guidelines and requirements, especially in relation to the promise of stable APIs and ABIs, compile-time options, etc.: http://apr.apache.org/versioning.html http://svn.apache.org/viewvc/httpd/httpd/trunk/VERSIONING?view=markup Axis2/C also installs a lot of libraries, and as such, I'd suggest that it follow the same guidelines that APR does, with respect to parallel installation and library naming: http://www106.pair.com/rhp/parallel.html Such a scheme allows, for example, a libwoden-2.so from a future Axis2/C installation to be installed alongside a libwoden-1.so from a previous installation. One interesting issue is that Axis2/C is contains both applications, like httpd, and libraries, like APR. It also contains a number of related sub-projects. It allows for third-party service modules to be written against its API, like httpd. And it may compile its own "third-party" modules (e.g., mod_axis2) for use with httpd. These complexities probably mean that we need to develop a fairly comprehensive set of versioning rules, and possibly make some changes to the installation process (e.g., to follow the parallel installation guidelines above) prior to announcing a 1.0 or 1.0.0 stable release. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B --------------------------------------------------------------------- To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org For additional commands, e-mail: axis-c-dev-help@ws.apache.org