Suggestion: Split Flex SDK into Flex-Core and Flex-More

[Gary McGhee <su...@buzzware.com.au>]

In order to free up the Flex SDK to move forward, I'm thinking it would be advantageous to split the SDK into "Flex-Core" and "Flex-More" like Merb (a Ruby library that merged with Rails).

This would mean that the compiler, standard libraries and core components could move forward in versions more freely, eg. without fringe components necessarily being updated. 
Also popular third party libraries could more easily be included into Flex-More. 

When it comes time for FalconJS, it could aim to support just the components in Flex-Core to begin with, and projects too could just depend on it without Flex-More.

This would be easier to manage too if a package manager became a core component as previously suggested, in fact it would make it easy to break the SDK into even more chunks.

Re: Suggestion: Split Flex SDK into Flex-Core and Flex-More

[Nicholas Kwiatkowski <ni...@spoon.as>]

Gary,

Personally, I'm not a big fan of this.  I've seen some other languages do
this, but I've also been stuck in "dependency hell", even for seemingly
core components.  We also have to play the balance game as far as what is
licensed under the Apache License, and what isn't as well (for example, we
wouldn't be able to include code that is not certified as properly licensed
-- meaning code that is not written by contributors).

I like the idea of having a central repository of Flex code, and addons.
 This maybe something that we can post on our wiki or website.  Linking to
them allows people to understand the license model that each of those
components are under which would allow us to host more components (for
example, like the ESRI or IBM component sets).

-Nick

On Tue, Jul 10, 2012 at 4:54 AM, Gary McGhee <su...@buzzware.com.au> wrote:

> In order to free up the Flex SDK to move forward, I'm thinking it would be
> advantageous to split the SDK into "Flex-Core" and "Flex-More" like Merb (a
> Ruby library that merged with Rails).
>
> This would mean that the compiler, standard libraries and core components
> could move forward in versions more freely, eg. without fringe components
> necessarily being updated.
> Also popular third party libraries could more easily be included into
> Flex-More.
>
> When it comes time for FalconJS, it could aim to support just the
> components in Flex-Core to begin with, and projects too could just depend
> on it without Flex-More.
>
> This would be easier to manage too if a package manager became a core
> component as previously suggested, in fact it would make it easy to break
> the SDK into even more chunks.
>
>

Re: Suggestion: Split Flex SDK into Flex-Core and Flex-More

[Jonathan Campos <jo...@gmail.com>]

On Tue, Jul 10, 2012 at 3:54 AM, Gary McGhee <su...@buzzware.com.au> wrote:

> In order to free up the Flex SDK to move forward, I'm thinking it would be
> advantageous to split the SDK into "Flex-Core" and "Flex-More" like Merb (a
> Ruby library that merged with Rails).


This is actually an idea I like. I don't like the idea that people think
every new version needs to have HBox/HGroup/H-Whatever equivalents. This
would make it so that some people can work on the core and it's performance
and all tertiary libraries just bask in the updating goodness.

-- 
Jonathan Campos