Yeah just concerned with an official build number, or date, or something
with numbers we can use to identify a production app back to what SDK was used
to compile it. Imagine having an app released on production and a user reports
a problem. We would need to reproduce the problem in a test environment. This
would include using the same SDK to compile the app. Currently in Flex, we can
just access its version directly which makes things faster.
If the SDK doesn't have anything like this at the moment and we did add
that functionality in there, I would say let's just use a date field since it
could be automated. Something like YYYYMMDD type format.
-Mark K
-----Original Message-----
From: Alex Harui [mailto:aha...@adobe.com.INVALID]
Sent: Friday, April 26, 2019 12:02 PM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale version
to 1.0)
On 4/26/19, 4:29 AM, "Kessler CTR Mark J" <mark.kessler....@usmc.mil.INVALID>
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
