To be more specific: Version.as in Flex was included into every class. I do not recommend doing that in Royale. It didn't have enough value for the cost.
FlexVersion.as in Flex was used for runtime versioning. Code could use it to take different paths. I hope we don't need that in Royale. The Flex and Royale compilers will put the compiler version in SWFs but do not put any string in JS output. Someday, the Royale compiler may be released separately from the SWCs. Royale may stop releasing certain SWCs in the future if there is no interest in maintaining them. Then we will have to decide whether to update the version of those SWCs after they are frozen. Royale SWCs do not carry version information on a per-SWC basis. But in some future, you could be using some version of the Royale compiler to compile with SWCs from different versions of the Royale SDKs. This version information is defined in the pom for folks using Maven. It is not defined at all for other build mechanisms (Ant, command-line, IDEs) because the non-Maven artifacts do not have versions in the file names. That's on purpose. We want to make it easy for non-Maven users to swap versions of SDKs. Maven users prioritize explicit dependency information over swapping of SDK versions. In summary, Royale may not be released like Flex where all SWCs are updated for each release along with a compiler. So I'm not exactly sure what problem is trying to be solved, but it won't hurt to have a version bead or version constant. And if someone wants to propose a way to get the compiler to inject a version string in JS output, that's fine too, but keep in mind that all of these verions strings might get removed during minification so they will probably need to be an exported public variable/constant. It would be great to have the version automatically updated for each release, but I think the number of places we currently change are small so having one more place probably is ok. All it takes is a volunteer to create the PRs or commit the code. My 2 cents, -Alex On 4/30/19, 2:17 PM, "Carlos Rovira" <[email protected]> wrote: Well, since others techs make that maybe it would be ok to have it baked. Right now I don't have a strong opinion about what to do maybe others could bring more light, but Version class seems ok to me, and hope we could have it get the version directly without manual modifications what will very cumbersome to manage for releases, niglhly builds, etc.. El mar., 30 abr. 2019 a las 22:14, Mark Kessler (< [email protected]>) escribió: > Well that would work in addition too, but not replace what I'm talking > about. I'm talking about the SDK having a built in version. A > version bead would be more building an app using the SDK and the app > having it's own version. > > > -Mark K > > On Tue, Apr 30, 2019 at 2:39 PM Piotr Zarzycki > <[email protected]> wrote: > > > > +1 to Josh's idea that we provide bead with logic which serves version. > > > > Thanks, > > Piotr > -- Carlos Rovira https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C5cf03e97fd1e4d637be208d6cdb14239%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636922558582228586&sdata=lF%2FwGT5b6MoKml%2BocTXLOxuaukVn7%2BkkdgRmUE59EuY%3D&reserved=0
