[jboss-dev] AS5.x, AS6 roadmaps

[Brian Stansberry]

Carlo de Wolf wrote:
> Tied to this is what we're going to do with the branches.
> 
> We need a branch to get to EAP 5 which will contain fixes which are not 
> backwards compatible with AS 5.0 GA, by definition this rules out 
> Branch_5_0. For community purposes we should only have to use trunk, 

If we are going to do significant (i.e. not just simple bug fixes) work 
toward an EAP, we should release a community version when that work is 
complete (i.e. when we hand it over to QA for the extra-extensive 
pounding that an EAP gets). Otherwise the work we do doesn't get the 
benefit of community review.

If we do that work on trunk, then we're limiting what we do over the 
next X weeks to EAP-compatible stuff.

> so 
> effectively Branch_5_0 is a dead branch unless we need to do a 5.0.1. So 
> we might as well startup the EAP branch right away.

An EAP branch should happen when we create a community release and then 
turn the code over to QA.

> 
> In AS trunk we can pursue the plan outlined below by Scott. Meanwhile I 
> would say we create an AS 6 project in which we build 6 as we envisioned 
> it in the first place: JBoss Bootstrap (MC, VDF etc) + JBoss Profile 
> Service. For the first iteration we can hardcode one profile: JavaEE 6 
> until the Profile Service is up and running. That means any components 
> coming free out of the AS 5 (/trunk) refactoring can immediately be 
> incorporated into AS 6. At some point the refactoring of AS 5 will make 
> it look almost exactly as AS 6 or AS 6 will become fully operational. At 
> which we deprecate AS 5 (/trunk).
> 
> Carlo
> 
> Scott Stark wrote:
>> We need to finalize the 3 month road map for AS5.x and its relation to 
>> AS6. The current discussions have been around embedded and EE6 type 
>> profiles and that we should focus on incorporating AS6 elements in the 
>> next AS5.x release that improve the following areas:
>>
>> * Unit Test Capabilities.  The ability to embed JBoss inside unit 
>> tests so that they can be run with no special plugins within an IDE, 
>> vanilla maven testsuite, vanilla ant testsuite.
>> * Maven JBoss Plugin.  You can define a configuration or override the 
>> default.  Basically making it nice and easy to use for maven people.
>> * Bundling of embedded jopr for the management console
>> * Get on-demand working for as many services as possible
>> * Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
>> * Deprecate and prune components and move them to a deprecated folder 
>> so that they don't boot up with default config. (Web Console, 
>> JMX-Console, Scheduler, EJB 2.x)
>> * Clean up service dependencies so its easier to add/remove components 
>> and subsystems.  This is related to on-demand as well.
>> * Define proper packaging of services so that dependencies and 
>> isolation of implementation details exist.
>> * Profile service supporting subprofiles and proper repository 
>> abstraction to allow for simple requirements descriptions of services 
>> in a profile driving the post MC bootstrap loading of services.
>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com