[jboss-dev] AS5.x, AS6 roadmaps

[Brian Stansberry]

Dimitris Andreadis wrote:
> Regarding EAP5, my suggestion is to stick with Branch_5_0 and continue 
> work there. If at some point we *have* to consider non-backwards 
> compatible changes, then we can branch off Branch_5_1 from the latest 
> Branch_5_0. Or even stay with Branch_5_0 if the changes are not 
> significant.
> 
> What are the non-backward compatible changes anyway? That's the real 
> question to ask. If we are certain of those we could Branch_5_1 now. The 
> key is that we don't want to deviate much from 5.0.0.GA. Otherwise all 
> the testing and stabilization we have done is lost.
> 
> About trunk, I think we should point to AS6 Alpha. To try experimenting 
> with a different Bootstrap+ProfileService type of setup either create 
> another working branch or an external project (JBoss Reloaded or 
> whatever) and merge back when done.
> 

Are you suggesting we continue dev on Branch_5_whatever after the next 
release in a few months? And then work toward AS6 Alpha continues in 
parallel on trunk? Or is it more that Branch_5_whatever dies after the 
next release?

Here's my concern about the latter: I'm a bit tired of working on major 
releases. :-) Tired because they alter priorities; a major release 
defines APIs that you expect to have to live with for several years. So 
small things that might impact API take high priority, higher than they 
otherwise would.

I'd like to see a few minor (not micro) releases, which give us the 
flexibility to change lots of stuff without bringing in the overhead of 
calling it "AS 6". If what we want to do over the next 6 months is such 
a big change that it should be a major release, well, c'est la vie, but 
let's not put a major release as next on the roadmap until we know the 
scope requires it.

Note that EE 6 doesn't have to mean AS 6. Not if the components that 
make up the AS work in the way Carlo wants EJB3 to work -- a backwards 
compatible core that exposes EE 5 or EE 6 facades. With that a 5.x 
server could have an EE 6 profile and an EE 5 profile. Or, while we work 
on EE 6 a 5.x server could have a partial EE 6 profile and and EE 5 profile.

> I think the key is to keep trunk relatively usable and stable. If we 
> start breaking things here and there we'll repeat the same mistakes we 
> did with AS5; the whole thing will soon get out of control.
> 
> 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, 
>> 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.
>>
>> 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
> _______________________________________________
> 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