Why don't we: - keep ONE "x.y" quiet i.e. don't do much work on them - keep the following "x.y+1" branch open to changes for some time (i.e. innovation period - then x.y+1 becomes the quiet branch - and we create a x.y+2 crazy branch

That way we always have a PUBLIC branch with releases where we don't have to observe any backward compatibility rules which would prevent innovation. And if users want fixes on the quiet x.y branch, either they do it by themselves or they use the EAP. In this case: - the quiet branch would be 5.0 (don't touch it anymore) - the crazy branch would be 5.1 - in a few months, 5.1 becomes a quiet branch (or you rebrand it 5.2 if you want to avoid confusion)

The reason why I think we need a crazy branch is that if we just use "beta" and "alpha" qualifiers then i) we don't do much releases and ii) people tend not to test them and provide feedback. By having a real branch with real z-dot releases you really open it to the user-community. > -----Original Message----- > From: jboss-development-bounces(a)lists.jboss.org [mailto:jboss- > development-bounces(a)lists.jboss.org] On Behalf Of Carlo de Wolf > Sent: vendredi, 16 janvier 2009 12:01 > To: dimitris(a)redhat.com; JBoss.org development list > Subject: Re: [jboss-dev] Include Web Beans RI in next JBoss 5 release > > I agree with both arguments. We must stick to rule we set for > versioning. But we must also have a means to bring in new technologies > onto the AS platform. > > For me I don't see option (b) happening in a fashion project leads want > to benefit of it. Most likely we'll have a quarterly or bi-monthly AS > release, while I would want a bi-weekly release of EJB3. > > That's the reason why we're working on the EJB3 plugin. It works in a > similar manner to the WB RI update. Use ant to patch AS. > > In future this is going to be handled by the patching functionality of > the Profile Service. It'll be backed up by a Maven repository where > it'll download the version of a bundle/package specified by the > administrator. > > Some stuff I don't see happening, for example OSGi class loading > bundles. For example, jboss-metadata must only appear once because else > JBossSessionBeanMetaData != JBossSessionBeanMetaData anymore and you > can > visualize how WB, WS, REST are ignoring EJB 3.1 beans. > > Other things I think we should be able to do now like a meta xml > describing the bundle/package and it's dependencies, jarring it up, > putting that into a Maven repo and downloading it (and the dependencies > again). > > Merging of config files will be an interesting problem and thus left > out > of scope for the moment. :-) > > Installation of jar files can for the moment be handled by Ant. > > So you'll get something like: > > repository.jboss.org/maven2/org/jboss/metadata/jboss-metadata- > 1.0.0.package > repository.jboss.org/maven2/org/jboss/metadata/jboss-ejb3-1.0.0.package > repository.jboss.org/maven2/org/jboss/metadata/jboss-webbeans- > 1.0.0.package > > Each containing: > META-INF/jboss-profile.xml > META-INF/jboss-package-build.xml > lib/myjars.jar > > With jboss-package-build.xml targets: install, uninstall. > > Now I can see some mismatch between this idea and the Profile Service > designs, so I would like to move the EJB3 plugin to the next step > without slicing my fingers. > > Note that developing in Branch_5_x and releasing against AS 5.0.0 is > impossible. Been there, done that. ;-) > > Carlo > > Threads on Profile Service: > [1] http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201376 > [2] http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192175 > > Dimitris Andreadis wrote: >> I must say I'm enjoying this discussion :) >> >> I think the answer is simple, really. If we want to: >> >> (a) respect our versioning strategy (major/minor/point) >> (b) speed up the release cycle >> >> then we need to push features to minor releases. Project leads will >> always want to include their latest stuff to whichever is the next AS >> release, the reason being we didn't respect both (a) & (b) in the >> past. And I have too many stories to tell of "smallish" changes with >> cascading dependencies or causing unpredictable results. >> >> As it is now Branch_5_0 looks pretty stable testsuite/tck-wise and >> that makes my life a lot easier if I want to make the release date, > so >> why risk breaking it? >> >> Besides 5.1 shouldn't be far way, end of February most probably. And >> if you are too eager to integrate, perform your work in >> Branch_5_x/trunk, then test against 5.0.x and release the webbeans >> deployer independently. >> >> Exception to the rules will always be, but let's try to stick to the >> rule first :) >> >> David M. Lloyd wrote: >>> Yes: 5.0.x is a stable branch and should only get bug fixes. >>> >>> By all means, integrate it into 5.1. But if it were me running the >>> project, I'd say, make sure that when it does get into the 5.x > branch >>> that it is stable (a GA release), as merging snapshots and betas and >>> CRs at this stage will serve only to delay the release which is >>> supposed to be on a fixed schedule now. >>> >>> The point of my email really has nothing to do with Web Beans - I >>> don't really know the status at all. I was just trying to get >>> Dimitris to be more assertive - he just seems so darn apologetic and >>> polite all the time. :-) >>> >>> I would take it even a step farther and say that Dimitris should > have >>> a fixed window during which people are allowed to merge new features >>> into the 5.x branch (which should be on a public calendar > somewhere), >>> to give plenty of time to get the release stable before doing the >>> release. But I guess he'll only put up with me telling him how to > do >>> his job for so long before telling me to get bent :) >>> >>> - DML >>> >>> On 01/15/2009 06:33 AM, Pete Muir wrote: >>>> Do you have a reasoned argument (other than a needing a quick power >>>> trip) about why we should not be pushing new software that we >>>> develop into JBoss AS (clearly marked as a technology preview), to >>>> allow early access and increase the feedback we get?For example, >>>> EJB3 was optionally included in JBoss 4.0.x. >>>> >>>> Reading between the lines, I hope that this will address your > concerns: >>>> First, please see https://jira.jboss.org/jira/browse/JBAS-6371 - > you >>>> can see that I am suggesting 5.1 as the place to introduce WB. >>>> >>>> Second, as I stated earlier (obviously not clearly enough) we built >>>> the integration such that none of the WB libraries are included in >>>> the AS or application classpath unless the deployment is a Web > Beans >>>> deployment (as marked by a {META-INF|WEB_INF}/web-beans.xml). Of >>>> course, this doesn't apply to the WB deployers which deploy the > app, >>>> and push the WB libraries onto the app classpath. Thus, whether or >>>> not WB is stable, shouldn't affect non-web-bean apps applied to the > AS. >>>> On 14 Jan 2009, at 22:11, David M. Lloyd wrote: >>>> >>>>> Dimitris, you worded that wrong. You should have said: >>>>> >>>>> "We are ABSOLUTELY NOT integrating Web Beans into 5.0.1. But I >>>>> will ALLOW you to merge a STABLE implementation into 5.1." >>>>> >>>>> Let them know who's boss. :-) >>>>> >>>>> - DML >>>>> >>>>> On 01/14/2009 04:03 PM, Dimitris Andreadis wrote: >>>>>> Shouldn't we leave the webbeans integration for 5.1? (Branch_5_x) >>>>>> >>>>>> 5.0.1 is a bug fixing release... >>>>>> Scott Stark wrote: >>>>>>> In going through the integration of the current webeans >>>>>>> 1.0.0.Alpha1 RI with the jbossas-5.0.0.GA release, the number >>>>>>> guess example fails to deploy on startup with: >>>>>>> >>>>>>> Caused by: java.lang.NullPointerException >>>>>>> at >>>>>>> > org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.loo > kup(EjbDiscoveryEnvironment.java:123) >>>>>>> at >>>>>>> > org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.<in > it>(EjbDiscoveryEnvironment.java:41) >>>>>>> at >>>>>>> > org.jboss.webbeans.integration.jbossas.WebBeanDiscoveryImpl.<init>(WebB > eanDiscoveryImpl.java:25) >>>>>>> ... 65 more >>>>>>> 10:30:59,909 INFO [WebBeansBootstrap] Starting Web Beans RI >>>>>>> 1.0.0.ALPHA1 >>>>>>> 10:30:59,909 ERROR [[/webbeans-numberguess]] Exception sending >>>>>>> context initialized event to listener instance of class >>>>>>> org.jboss.webbeans.servlet.WebBeansListener >>>>>>> >>>>>>> So I guess we need to focus on web beans integration tests as > well. >>>>>>> _______________________________________________ >>>>>>> jboss-development mailing list >>>>>>> jboss-development(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development