Falcon is tied to the SDK, the text components in the SDK are tied to TLF, the networking classes in the SDK are clients of BlazeDS, etc. Flex is an ecosystem that all works together and you can't just mix-and-match any version of one part with any version of another part.
But I now agree with Alex and others that the various subparts need to be able to evolve independently rather than all being in a single trunk. So that means we need some way of tying them all together in order to test, or in order to produce a "here's everything you need" release, and I don't think we're clear on how that might work. But I'm sure we can figure something out. - Gordon -----Original Message----- From: omup...@gmail.com [mailto:omup...@gmail.com] On Behalf Of Om Sent: Wednesday, August 15, 2012 12:19 PM To: flex-dev@incubator.apache.org Subject: Re: Falcon location On Wed, Aug 15, 2012 at 11:44 AM, Omar Gonzalez <omarg.develo...@gmail.com>wrote: > > > > IMO, you are arguing against the principle of modularity and/or > separation > > of concerns. Yes, there is a bit more overhead, but is should be > > worth > it. > > You voted for a much more complex branching strategy supposedly in > > favor > of > > modularity. I'm surprised you are pushing back on it here. > > > > -- > > Alex Harui > > Flex SDK Team > > Adobe Systems, Inc. > > http://blogs.adobe.com/aharui > > > > > This ^^^. > > -omar > I am sorry if I sound like I dont support modularity. But that is not what I am saying here. By Gordon's (who is probably the only person on this list who knows the Falcon codebase) own admission, Falcon is tied closely to the Flex framework because of the semantics of MXML. I agree that this is not a good thing. I agree that this should be changed. But, until that level of separation is achieved, how can I as a developer make sure that Falcon works with the current sdk that I want to ship in the next release? I keep seeing the word 'eventually'. All I am saying is, in that eventual case, lets make Falcon a top level project. There is nothing preventing anyone from modularizing and separating the concerns of Falcon while still under modules/falcon. But the other way round, making Falcon a top level project prevents me from working with it in the short term. Alex: > Yes, there is a bit more overhead, but is should be worth it. > How do we know if it is worth it if we don't know what exactly the overhead is? No one has proposed a workflow to working with Falcon as a top-level project yet. Whereas, I am proposing a workflow which is to keep Falcon under modules and create a separate branch where this would be the main feature. Anyone who wants to work with Falcon can simply switch to that feature branch. Convince me why this is not a better idea. The only reason against it so far is: "it will be confusing". Why is this confusing? Thanks, Om
