Hi Folks,

Getting some sort of checkintest infrastructure was the last "must-have"
on my list before starting the process of cutting our first FlexJS
release.  Below is a list of things I thought about doing, but since this
is 'alpha' I think we don't have to wait.  That said, we do want to make a
good first impression and have enough functionality that it seems real and
not just a toy.  If you have other things you think are must-have, let's
discuss here.

My list of possible must-haves:

1) Do some package reorganization:  Currently most components are in
org.apache.flex.html.staticControls.  However these controls aren't quite
so static, so I'm thinking of removing the staticControls folder and
flattening the hierarchy by one level.
2) Choose a different/better xml prefix:  Right now we are using
xmlns=basic.  That's five characters which is longer that I'd like.  I've
thought about replacing with "fjs" or 'af' or 'js' or even 'fxjs' but a
shorter prefix means less typing.
3) Take another look at the FlashBuilder versioning issue.  Right now
FlexJS is going to go out as versions 4.0.1 instead of a more alpha-like
0.0.1 because of some hard-coded assumptions in FlashBuilder.
4) Take a look at not using MXMLC and going for it with Falcon.  This
would make the install simpler and might make it easier for other IDEs to
work with FlexJS, but we could end up dealing with a lot of Falcon issues.
5) More tests.  I'm going to spend part of today verifying the FlexUnit RC
and seeing if I can write a couple of FlexJS unit tests in FlexUnit.  But
I'm not sure that's required for a first release.

Basically, I think it is time to get an official release out the door for
folks to try.  Yes, the changes above might have backward compatibility
impact on folks using these first releases, but IMO, if we set expectation
correctly, folks will be flexible.

Thoughts?
-Alex

Reply via email to