On 4/26/19, 4:29 AM, "Kessler CTR Mark J" <[email protected]>
wrote:
> So far, we have not had the release scripts properly generate the right
version number for the NPM artifacts.
This spurred a question for me. Is there a way to find out what version
number the SDK binaries are in code for Royale? Sort of like the Flex SDK
mx.core.FlexVersion or at least a build date?
Not at this time. IMO, runtime versioning wasn't worth the cost of all of
those strings and code in the production app. Also, Royale was designed from
the beginning to try to be "version-agnostic". By using loose-coupling via
Beads/PAYG/ValuesManager and lots of interfaces instead of direct class
references, there shouldn't be a need to deal with version incompatibilities at
runtime like Flex did with the Marshall Plan and FlexVersion and more.
Flex had to care about version incompatibilities because the fundamental base
classes were not loosely-coupled. Flex HelloWorld was 128K not just because
UIComponent was huge, but because UIComponent pulled in other classes as
init-time strongly-coupled dependencies. A good thing to think about as you
write Royale framework code is, "can every dependency be easily replaced"?
After we hit 1.0 (and hopefully find some volunteers to write regression
tests), then new APIs to existing classes will need to be considered carefully
and implemented in extensions. So there will be some extension of IUIBase that
has some new API instead of adding new APIs to IUIBase. I have a personal
preference to use long names instead of numbers, so the extension will
hopefully be called IUIBaseWithWhatever instead of IUIBase2.
If you are asking about build-time versioning, we haven't done anything there
either. As long as there is no impact on production apps I think it is fine
for folks to contribute something if there is a need.
My 2 cents,
-Alex
-Mark K
-----Original Message-----
From: Alex Harui [mailto:[email protected]]
Sent: Friday, April 26, 2019 2:44 AM
To: [email protected]
Subject: [Non-DoD Source] Re: Let's bump Royale version to 1.0
I do not have an opinion on what technical/marketing criteria we use to
decide which release to call 1.0. I'm not working directly with
users/customers.
I do not currently have time/energy/budget to work on any of the things
folks think need to be done to get to 1.0 and barely have enough time to work
on getting the next release out. So someone else will have to supply the
time/energy/budget to get these tasks done.
I do have an opinion based on a practical aspect. So far, we have not had
the release scripts properly generate the right version number for the NPM
artifacts. That's why we've jumped from 0.9.4 to 0.9.6 and skipped 0.9.5. So
I would say we should not call this next release 1.0 and wait until the release
automation can correctly version all artifacts with the right version number
before we pick one to call 1.0. With any luck I'll get the automation running
next week and will ask for someone to volunteer to test drive it.
-Alex
