On Fri, Nov 20, 2009 at 10:27 AM, Simon Laws <[email protected]> wrote: >> I think it would be good to wait till there are some official final >> published specs if thats not going to be too far away, i heard that >> may happen around February which sounds ok. > > +1, I wasn't suggesting otherwise. > >>Doing a 2.0 release before >> any specs are final seems premature, and there is quite a lot we still >> need to finish anyway. Is there any reason we'd need to go for a 2.0 >> done sooner than that? > > No, you will notice I made no mention of when a release might happen > just that it would be a good idea to discuss (as we are doing here) > what might be in it. Until we have some idea of what we would like to > have in it talk timescales is futile. >> >> The 2nd email asked about switching from milestone releases to a beta >> release which is a different question. One comment on that is that >> there were disagreements on what to name the releases leading up to >> the the Tuscany 1.0 which seemed to come from there not being precise >> definitions on what names like milestone/0.9x/beta/RC etc mean exactly >> so different people have different expectations. So what are the >> reasons for wanting to change to beta? If beta is going to imply no >> more API/SPI changes (and thats what it does imply to some) > > That's what it implies to me. But I agree there is no hard an fast > definition. We can't though go on forever doing milestones. As some > point in time we got do declare victory and decide that, for example, > we are pretty much happy with the SPI. > >> then I >> dont think we're quite ready for that, > > Again, I didn't say we were. > > if beta is just going to mean >> "closer to being done so come try it out but things may still change a >> bit" then i dont really mind either way. >> >> I guess a similar thing goes for when to call it 2.0. Some say sooner >> as then you'll get more people trying it out, others say later so its >> more polished so when people try it they're more impressed. I do think >> we released 1.0 too early and the rough edges put some people off and >> we should try to avoid that with 2.0. > > Back to my original message. I think we should define what we think a > minimal 2.0 is in terms of function is. That at least gives us > something to shoot for. At the moment it feels as though we are > drifting. Again, I repeat, I'm *not* pushing for any particular > timeframe. This will come as a result of the functional content and > how happy we are with the code stability based on that content. > >> >> I also think having 2.0 waiting for things to get done is a good >> motivator to make things get done. > > Right, although I'm repeating myself, I'm suggesting we simply list > what those things might be. > > Along with the conformance tests >> passing for those main specs, > > Let's be explicit here to see if you agree > > Assembly > Policy > JCAA > JCI > binding.ws > binding.jms > (impl bpel as a stretch) > > Again, following up in my 2nd post, if others are ready also then > great. I'm trying to define the minimum set no the maximum set. > > I'd like to see the distributed domain >> working well, > > +1 > > some of the non-spec tuscany extensions working well > > Which ones did you have in mind? > >> (i.e. consistent support for things like >> async/callbacks/java/wsdl/wireformats etc), > > +1 to consistency > > an easy to use >> distribution, and decent samples and documentation. We're not that far >> from those but there is work to do. > > +1 > >> >> FWIW I'd been thinking along the lines of a release just before >> Christmas which in my mind I've been calling M5, > > +1 > > then another release >> or two before a 2.0 final depending on whats happening with the specs >> perhaps around March. >> > > If I were forced to pick a date March would seem like an appropriate > target to aim for. > > Simon >
Here's what i think would work for deciding when 2.0 is done - look at the reasons we say Tuscany and SCA are useful and for 2.0 try to make those things work well. For example, one thing we say about SCA is that although there are other technologies for doing in-VM assembly there aren't many for doing distributed assembly so lets make sure this works really well so as to highlight that. Things like the distributed domain, running domains in different runtime environments, using non-SCA clients, doing dynamic re-wiring and policy etc. Another unique feature of SCA is declarative policy but whether or not we pass the policy conformance tests all we really show right now is a logging policy which isn't terribly useful, so being able to support something more useful like transactions or security would be terrific. One benifit we say of Tuscany/SCA is that its standards based so lets make sure most of the function complies with the standards. That doesn't mean 2.0 needs to pass _all_ the conformance suites, but to be credible most function should be based on a spec and mostly passing the test suites. And for other non-spec Tuscany specific function to work in similar ways to the spec defined function, so using things like wireFormats or operationSelectors as appropriate. SCA says you should be able to swap and change things like bindings, implementations, and runtime environments and have it just work - but right now lots of things don't work consistently. Some extensions only run in some environments, or with certain combinations of implementation/binding, async and callbacks don't work across some extensions, even something relatively basic as using interface.wsdl instead of interface.java breaks some extensions. It doesn't need to be perfect but to be credible most things should just work together. A lot of those things are close to being done and its just cleaning up rough edges, there is quite a bit of work when its all added together, but I think we could get it all done by Feb/March. ...ant
