Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 46677 invoked from network); 16 Nov 2009 15:06:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Nov 2009 15:06:43 -0000 Received: (qmail 78086 invoked by uid 500); 16 Nov 2009 15:06:43 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 78025 invoked by uid 500); 16 Nov 2009 15:06:42 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 78015 invoked by uid 99); 16 Nov 2009 15:06:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Nov 2009 15:06:42 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [216.40.44.246] (HELO smtprelay.hostedemail.com) (216.40.44.246) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Nov 2009 15:06:31 +0000 Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with SMTP id EFF2A5161FC for ; Mon, 16 Nov 2009 15:06:09 +0000 (UTC) X-Spam-Summary: 50,0,0,edd819e762bcbcb8,907452bc8cfe1759,dkulp@apache.org,dev@cxf.apache.org,RULES_HIT:355:379:945:967:973:988:989:1260:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1766:1792:2198:2199:2393:2525:2553:2560:2563:2682:2685:2687:2693:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3834:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4560:5007:6114:6261:7679:7903:8501:8957:8985:9025:9388,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fu,MSBL:none,DNSBL:none X-Session-Marker: 64616E406B756C702E636F6D X-Filterd-Recvd-Size: 2418 Received: from server.dankulp.com (server1.dankulp.com [66.207.172.168]) (Authenticated sender: dan@kulp.com) by omf05.hostedemail.com (Postfix) with ESMTP for ; Mon, 16 Nov 2009 15:06:09 +0000 (UTC) Received: by server.dankulp.com (Postfix, from userid 5000) id 409F8507001D; Mon, 16 Nov 2009 10:06:09 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.1-gr1 (2007-05-02) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter.eiB8XnIJpx Received: from dilbert.localnet (c-24-91-141-225.hsd1.ma.comcast.net [24.91.141.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTPSA id 6B4815070016 for ; Mon, 16 Nov 2009 10:06:08 -0500 (EST) From: Daniel Kulp To: dev@cxf.apache.org Subject: Thoughts about dropping support for 2.1.x...... Date: Mon, 16 Nov 2009 10:05:58 -0500 User-Agent: KMail/1.12.3 (Linux/2.6.32-rc6; KDE/4.3.3; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200911161005.58449.dkulp@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-3.4 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1-gr1 Question for everyone..... What are peoples thoughts about making 2.1.9 (in January) the last of the 2.1.x line? 2.2.x will have been out for 10 months by then so users definitely should have had plenty of time to migrate. 2.2.x is generally a simple migration from 2.1.x. I think most of the other major open source projects that were tracking 2.1.x have already moved onto 2.2.x. ServiceMix, Camel, JBoss, etc... The remaining projects that are using 2.1.x seem to be stuck on a particular version (like Mule stuck on 2.1.3) and not "tracking" the fixes anyway. The main migration issue from 2.1.x to 2.2.x is the JAX-RS version (0.8 -> 1.0). However, we aren't fixing any of the JAX-RS issues on 2.1.x anyway. Thus, that's not a real reason. If you are using JAX-RS, you definitely want the compliant implementation in 2.2. Anyway, making 2.1.9 the end of the line should then make it such that when 2.3 is ready (hopefully in Q1), we can just keep 2 fixes branches active. Thoughts? Comments? -- Daniel Kulp dkulp@apache.org http://www.dankulp.com/blog