Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of tim.mcconne@gmail.com
 designates 209.85.132.242 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding;
        b=Z0aLUe/z1DSD0XWgojKF36wFEdKdSxa2l8ECpzjneEvgobBdPzQ1vrvU9/8ubCNZUE09B7k19u1ysHWdxsi14WBKJm7aQoZpMYRJGKugUHXIdZ+AxvjUXpXO2qHpJGHbqDNYI4NmmIt/tRIe2UgYWDEWHwXGmySQ7RihSYdtSUo=
Message-ID: <47EDDF89.1070600@gmail.com>
Date: Sat, 29 Mar 2008 02:19:53 -0400
From: Tim McConnell <tim.mcconne@gmail.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: "[GERONIMO] dev-list" <dev@geronimo.apache.org>
Subject: [DISCUSS] GEP 2.1 support for v1.1
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the 2.0.x 
and 2.1.x versions of the Geronimo servers. Most major functions are now working 
and we are much better positioned to handle future schema changes in a more 
timely manner. Traditionally, the GEP has supported 3 to 4 versions of the 
Geronimo server (primarily to provide a migration/upgrade path), and we had 
originally planned on supporting v1.1, v2.0.x, v2.1.x. However, since we are 
almost 2 months behind the release of the v2.1 Geronimo server I would like to 
discuss some possible alternatives for supporting the v1.1 Geronimo server in 
this release of the GEP:

#1. Proceed with the JAXB refactoring work for the v1.1 code (obviously the most 
expensive in terms of time and testing required)

#2. Leave the v1.1 support in the current EMF implementation (i.e., the JAXB and 
EMF implementations would co-exist)

#3. Remove support altogether for v1.1 in this release of the GEP -- support 
only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time 
and testing required)

I'm now of the opinion that we should pursue alternative #3 and remove v1.1 
support entirely. My primary rationale is that the the old 2.0 release of the 
GEP can still be used to provide v1.1 server support, and still provides a 
migration path from v1.1 to v2.0. It's true that we would lose the v1.1 to v2.1 
migration path, but this is mitigated somewhat since the support in the GEP for 
the v2.0 and v2.1 versions of the server is almost identical. Equally important 
is that we could then focus entirely on fixing the few remaining JIRAs and 
augmenting our JUnit testcases, and release the GEP 2.1 quicker (i.e., in the 
next week or 10 days). Thoughts ??

-- 
Thanks,
Tim McConnell