Return-Path: 
 <dev-return-33200-apmail-hc-dev-archive=hc.apache.org@hc.apache.org>
X-Original-To: apmail-hc-dev-archive@www.apache.org
Delivered-To: apmail-hc-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 8B3D4187F3
	for <apmail-hc-dev-archive@www.apache.org>;
 Thu, 19 Nov 2015 11:34:02 +0000 (UTC)
Received: (qmail 64602 invoked by uid 500); 19 Nov 2015 11:33:57 -0000
Delivered-To: apmail-hc-dev-archive@hc.apache.org
Received: (qmail 64561 invoked by uid 500); 19 Nov 2015 11:33:57 -0000
Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@hc.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@hc.apache.org>
List-Post: <mailto:dev@hc.apache.org>
List-Id: <dev.hc.apache.org>
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Delivered-To: mailing list dev@hc.apache.org
Received: (qmail 64550 invoked by uid 99); 19 Nov 2015 11:33:57 -0000
Received: from mail-relay.apache.org (HELO mail-relay.apache.org)
 (140.211.11.15)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Nov 2015 11:33:57 +0000
Received: from ok2c (84.76.106.92.dynamic.wline.res.cust.swisscom.ch
 [92.106.76.84])
	by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with
 ESMTPSA id B6CEF1A0338
	for <dev@hc.apache.org>; Thu, 19 Nov 2015 11:33:56 +0000 (UTC)
Message-ID: <1447932726.2577.28.camel@apache.org>
Subject: HC 5.0: co-location with HC 4.x
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
Date: Thu, 19 Nov 2015 12:32:06 +0100
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.9-1+b1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Folks

I would like to start working on the first alpha releases of HC 5.0. 

There is one issue that still needs to be discussed though before I can
proceed. We need to decide on how we intent to maintain compatibility
with HC 4.x. It is pretty clear that maintaining full compatibility is
unrealistic and probably counter-productive. HC 5.0 is likely to have
different APIs especially once HTTP/2 transport is implemented. 

A pragmatic approach could be to make HC 5.0 and HC 4.x deployable
within the same class loader context (so called co-location). This is
what Apache Commons do with their major releases. We should do
likewise.  

Effectively co-location is about moving major releases to a new package
space like org.apache.commons.lang3, org.apache.commons.lang4, etc. I
think we should adopt a compatible scheme. The trouble is that when the
project was started in 2005 the choice of 'org.apache.http' was pretty
natural and in line with Jakarta practices (anyone here still remembers
Apache Jakarta?). Now it can be seen as too presumptuous. This would be
a good opportunity to fix that.

What would be a better name space for the project in your opinion?

org.apache.http<n>
org.apache.http.hc<n>
org.apache.hc<n>.http
where <n> is a major release version

Something else? Any thoughts or preferences?

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org