Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
I meant that the VersionBead would contain the Royale SDK version. A separate version bead for the app's version would be useful too, but that's not what I was suggesting. - Josh On 2019/04/30 20:14:31, Mark Kessler wrote: > 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 > wrote: > > > > +1 to Josh's idea that we provide bead with logic which serves version. > > > > Thanks, > > Piotr >
Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
> Regarding your other response, I'm not sure that grep worked with Ant on > Windows. It would be best to either have Ant generate the entire file or use > its replaceregex task on a known pattern. There already exists one of those. That's why I kept the current file name as it was. The following I found in the build.xml file in the root. It looks like it would almost work out of the box. Would just change the path to be more specific location. -Mark K On Tue, Apr 30, 2019 at 7:31 PM Alex Harui wrote: > > I'm fine with starting with your example. Are other versions in Royale > including the build number? Are you expecting the build systems to update > that file on each build? That might be trickier. The Maven builds check for > uncommitted files. > > Regarding your other response, I'm not sure that grep worked with Ant on > Windows. It would be best to either have Ant generate the entire file or use > its replaceregex task on a known pattern. > > My 2 cents, > -Alex >
Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
I'm fine with starting with your example. Are other versions in Royale including the build number? Are you expecting the build systems to update that file on each build? That might be trickier. The Maven builds check for uncommitted files. Regarding your other response, I'm not sure that grep worked with Ant on Windows. It would be best to either have Ant generate the entire file or use its replaceregex task on a known pattern. My 2 cents, -Alex On 4/30/19, 4:02 PM, "Mark Kessler" wrote: Don't need every SWC with a version. Just one for the whole SDK would be fine. I proposed just a single one stored in the core. We can modify the build file to just point to the single file instead of doing a path search. See the start of my example [1]. [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKesslerConsulting%2Froyale-asjs%2Fcommit%2F84262f3a2e56cc6b58ccdf283d039c94fb10cafb&data=02%7C01%7Caharui%40adobe.com%7Cd74e4fe942624e46e11708d6cdbfdac8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636922621260197257&sdata=9UFENmZCH%2BwoK3OJHx1e%2B85bu%2FhIeIr%2F94QS4NYO5xA%3D&reserved=0 -Mark K On Tue, Apr 30, 2019 at 6:42 PM Alex Harui wrote: > > 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 > >
Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
Don't need every SWC with a version. Just one for the whole SDK would be fine. I proposed just a single one stored in the core. We can modify the build file to just point to the single file instead of doing a path search. See the start of my example [1]. [1] https://github.com/KesslerConsulting/royale-asjs/commit/84262f3a2e56cc6b58ccdf283d039c94fb10cafb -Mark K On Tue, Apr 30, 2019 at 6:42 PM Alex Harui wrote: > > 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 > >
Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
We can through an old mechanism that appears to be left from the Apache Flex side that does just this. Around line1192 of the root build.xml [1]. It specifically hunts down files called "Version.as" and uses RegEx to update the version number and build number. So when the SDK is built for release, it will automatically update the Version.as files using the "release.version" property. Meaning after we create the file(Version.as) having the correct version format inside it it will be something that stays up-to-date automatically. Little tweaks needed it looks like, but it should work. build.xml lines look like this: I won't have a chance to test the build.xml right now to finish it, but here is what the rest of it would look like [2] (very short). Usage for the end user: import org.apache.royale.core.Version; trace(Version.CURRENT_VERSION); [1] https://github.com/apache/royale-asjs/blob/develop/build.xml [2] https://github.com/KesslerConsulting/royale-asjs/commit/84262f3a2e56cc6b58ccdf283d039c94fb10cafb -Mark K On Tue, Apr 30, 2019 at 5:17 PM Carlos Rovira 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.. >
Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
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" 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 (< kesslerconsult...@gmail.com>) 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 > 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
Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
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 (< kesslerconsult...@gmail.com>) 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 > wrote: > > > > +1 to Josh's idea that we provide bead with logic which serves version. > > > > Thanks, > > Piotr > -- Carlos Rovira http://about.me/carlosrovira
Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
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 wrote: > > +1 to Josh's idea that we provide bead with logic which serves version. > > Thanks, > Piotr
Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
+1 to Josh's idea that we provide bead with logic which serves version.
Thanks,
Piotr
On Tue, Apr 30, 2019, 8:18 PM Kessler CTR Mark J
wrote:
> As an example, here is how to access the version number in other
> languages. Some easier to use than others. Looks like the easiest ones
> are just static const strings.
>
> Flex[1]: mx.core.FlexVersion.CURRENT_VERSION
> Dotnet[2]: System.Environment.Version
> Java[3]:System.getProperty("java.version");
> React[4]: React.version
> Angular[5]: import { VERSION } from '@angular/core'; VERSION.full
> Groovy[6]: GroovySystem.getVersion();
> Ruby[7]: RUBY_VERSION
> Python[8]: sys.version
> Node.Js[9]: process.version
> PHP[10]: phpversion()
>
>
> So I would like the SDK to provide something similar. It looks like we
> still have a mechanism setup in the build.xml we are just missing the files
> it's looking for (Version.as files). Let's add the following file and see
> if it with a little tweak in pathing would turn it into a self-managing
> version file when building the SDK for release. This looks like a smallest
> simplest mechanism to implement this. Especially since it's regex pattern
> matching the old version format, it doesn't matter how we layout the file.
>
> File: Version.as
>
> package org.apache.royale.core
> {
> public class Version
> {
> public static const CURRENT_VERSION:String = "0.9.6.0";
> }
> }
>
>
> SDK Usage for developer:
> Import org.apache.core.Version;
> trace(Version.CURRENT_VERSION);
>
>
> [1] https://flex.apache.org/asdoc/mx/core/FlexVersion.html
> [2]
> https://docs.microsoft.com/en-us/dotnet/api/system.environment.version?view=netframework-4.8
> [3]
> https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
> [4]
> https://stackoverflow.com/questions/36994564/how-can-one-tell-the-version-of-react-running-at-runtime-in-the-browser
> [5]
> https://stackoverflow.com/questions/36456843/how-to-check-angular2-version-with-typescript
> [6]
> http://docs.groovy-lang.org/latest/html/api/groovy/lang/GroovySystem.html
> [7]
> https://stackoverflow.com/questions/1589751/determine-ruby-version-from-within-rails
> [8] https://docs.python.org/3/library/sys.html
> [9] https://nodejs.org/api/process.html#process_process_version
> [10] https://www.php.net/manual/en/function.phpversion.php
>
>
> -Mark K
>
>
> -----Original Message-
> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> Sent: Tuesday, April 30, 2019 10:37 AM
> To: dev@royale.apache.org
> Subject: Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale
> version to 1.0)
>
> Hi Mark,
>
> sorry but all you state can be solved with the solution I exposed to you.
> There's no need to add an identifier to an SDK since you can add it
> yourself from the SDK you downloaded or get by the multiple ways available.
> In any of the cases the numbers are not baked into code, but are available
> in different parts and you can use defines to bake it into your code and
> use it in the same way you use to do in Flex. At least I don't see from
> your response that your points will not be covered in that way
>
RE: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
As an example, here is how to access the version number in other languages.
Some easier to use than others. Looks like the easiest ones are just static
const strings.
Flex[1]: mx.core.FlexVersion.CURRENT_VERSION
Dotnet[2]: System.Environment.Version
Java[3]:System.getProperty("java.version");
React[4]: React.version
Angular[5]: import { VERSION } from '@angular/core'; VERSION.full
Groovy[6]: GroovySystem.getVersion();
Ruby[7]: RUBY_VERSION
Python[8]: sys.version
Node.Js[9]: process.version
PHP[10]: phpversion()
So I would like the SDK to provide something similar. It looks like we still
have a mechanism setup in the build.xml we are just missing the files it's
looking for (Version.as files). Let's add the following file and see if it
with a little tweak in pathing would turn it into a self-managing version file
when building the SDK for release. This looks like a smallest simplest
mechanism to implement this. Especially since it's regex pattern matching the
old version format, it doesn't matter how we layout the file.
File: Version.as
package org.apache.royale.core
{
public class Version
{
public static const CURRENT_VERSION:String = "0.9.6.0";
}
}
SDK Usage for developer:
Import org.apache.core.Version;
trace(Version.CURRENT_VERSION);
[1] https://flex.apache.org/asdoc/mx/core/FlexVersion.html
[2]
https://docs.microsoft.com/en-us/dotnet/api/system.environment.version?view=netframework-4.8
[3] https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
[4]
https://stackoverflow.com/questions/36994564/how-can-one-tell-the-version-of-react-running-at-runtime-in-the-browser
[5]
https://stackoverflow.com/questions/36456843/how-to-check-angular2-version-with-typescript
[6] http://docs.groovy-lang.org/latest/html/api/groovy/lang/GroovySystem.html
[7]
https://stackoverflow.com/questions/1589751/determine-ruby-version-from-within-rails
[8] https://docs.python.org/3/library/sys.html
[9] https://nodejs.org/api/process.html#process_process_version
[10] https://www.php.net/manual/en/function.phpversion.php
-Mark K
-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org]
Sent: Tuesday, April 30, 2019 10:37 AM
To: dev@royale.apache.org
Subject: Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale
version to 1.0)
Hi Mark,
sorry but all you state can be solved with the solution I exposed to you.
There's no need to add an identifier to an SDK since you can add it
yourself from the SDK you downloaded or get by the multiple ways available.
In any of the cases the numbers are not baked into code, but are available
in different parts and you can use defines to bake it into your code and
use it in the same way you use to do in Flex. At least I don't see from
your response that your points will not be covered in that way
Re: RE: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
I think is a good idea to create a bead. But maybe is not needed to add to
Express for example by default.
People that wants it could just add it in this main Application file in the
beads section.
I think this is a good opportunity to contribute it via PR, what do you
think Mark?
just my 2...
El El mar, 30 abr 2019 a las 18:00, Josh Tynjala
escribió:
> What if Royale had some kind of VersionBead that you could add to the main
> application? It could be optional with Basic, but maybe baked in by default
> with Express and other component sets that are less focused on small output
> size.
>
> - Josh
>
> On 2019/04/30 10:46:27, Kessler CTR Mark J
> wrote:
> > Lol, I can't seem to explain it properly. Take maven/ant/config files
> out of the equation it doesn't matter for this example. This has to do
> with getting some identifying information into the official SDK releases.
> We don't want to pass variables as an SDK user. We want the official SDK
> to already come packaged with a version number or a build number or a build
> date...
> >
> >
> > Here's the scenario that I would love to see happen:
> >
> > 1. SDK user downloads official Royale SDK release and never modifies it.
> >
> > 2. SDK User compiles their app using official SDK and references an
> official SDK property that contains the SDK identifier already built in
> it. Meaning I should be able to code complete off of the SDK and find
> something that already exists and could return me an official identifier.
> >
> >
> > -Mark K
> >
> > -Original Message-
> > From: Carlos Rovira [mailto:carlosrov...@apache.org]
> > Sent: Monday, April 29, 2019 1:14 PM
> > To: dev@royale.apache.org
> > Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale
> version to 1.0)
> >
> > ok,
> >
> > we do the following in maven for other needs so this will be valid for
> you
> > too:
> >
> > in your maven properties.
> >
> > 0.9.6-OR-WHATEVER
> >
> >
> > org.apache.royale.compiler
> > royale-maven-plugin
> > true
> >
> > ...
> >
> >
> > BUILD::royaleVersion
> > '"${royale.framework.version}"'
> >
> > ...
> >
> > ...
> >
> >
> > defines can be done in ANT, asconfigc, config.xml
> >
> > Then in AS3 or MXML
> >
> > /**
> > * ROYALE VERSION NUMBER
> > */
> > private static var _royaleVersion :String = BUILD::royaleVersion;
> >
> > So now you can use in any place you want
> >
> > HTH
> >
> > Carlos
> >
> >
>
Re: RE: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
What if Royale had some kind of VersionBead that you could add to the main
application? It could be optional with Basic, but maybe baked in by default
with Express and other component sets that are less focused on small output
size.
- Josh
On 2019/04/30 10:46:27, Kessler CTR Mark J
wrote:
> Lol, I can't seem to explain it properly. Take maven/ant/config files out of
> the equation it doesn't matter for this example. This has to do with getting
> some identifying information into the official SDK releases. We don't want
> to pass variables as an SDK user. We want the official SDK to already come
> packaged with a version number or a build number or a build date...
>
>
> Here's the scenario that I would love to see happen:
>
> 1. SDK user downloads official Royale SDK release and never modifies it.
>
> 2. SDK User compiles their app using official SDK and references an official
> SDK property that contains the SDK identifier already built in it. Meaning I
> should be able to code complete off of the SDK and find something that
> already exists and could return me an official identifier.
>
>
> -Mark K
>
> -Original Message-
> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> Sent: Monday, April 29, 2019 1:14 PM
> To: dev@royale.apache.org
> Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale
> version to 1.0)
>
> ok,
>
> we do the following in maven for other needs so this will be valid for you
> too:
>
> in your maven properties.
>
> 0.9.6-OR-WHATEVER
>
>
> org.apache.royale.compiler
> royale-maven-plugin
> true
>
> ...
>
>
> BUILD::royaleVersion
> '"${royale.framework.version}"'
>
> ...
>
> ...
>
>
> defines can be done in ANT, asconfigc, config.xml
>
> Then in AS3 or MXML
>
> /**
> * ROYALE VERSION NUMBER
> */
> private static var _royaleVersion :String = BUILD::royaleVersion;
>
> So now you can use in any place you want
>
> HTH
>
> Carlos
>
>
Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
Hi Mark,
sorry but all you state can be solved with the solution I exposed to you.
There's no need to add an identifier to an SDK since you can add it
yourself from the SDK you downloaded or get by the multiple ways available.
In any of the cases the numbers are not baked into code, but are available
in different parts and you can use defines to bake it into your code and
use it in the same way you use to do in Flex. At least I don't see from
your response that your points will not be covered in that way
El mar., 30 abr. 2019 a las 12:46, Kessler CTR Mark J
() escribió:
> Lol, I can't seem to explain it properly. Take maven/ant/config files out
> of the equation it doesn't matter for this example. This has to do with
> getting some identifying information into the official SDK releases. We
> don't want to pass variables as an SDK user. We want the official SDK to
> already come packaged with a version number or a build number or a build
> date...
>
>
> Here's the scenario that I would love to see happen:
>
> 1. SDK user downloads official Royale SDK release and never modifies it.
>
> 2. SDK User compiles their app using official SDK and references an
> official SDK property that contains the SDK identifier already built in
> it. Meaning I should be able to code complete off of the SDK and find
> something that already exists and could return me an official identifier.
>
>
> -Mark K
>
> -Original Message-
> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> Sent: Monday, April 29, 2019 1:14 PM
> To: dev@royale.apache.org
> Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale
> version to 1.0)
>
> ok,
>
> we do the following in maven for other needs so this will be valid for you
> too:
>
> in your maven properties.
>
> 0.9.6-OR-WHATEVER
>
>
> org.apache.royale.compiler
> royale-maven-plugin
> true
>
> ...
>
>
> BUILD::royaleVersion
> '"${royale.framework.version}"'
>
> ...
>
> ...
>
>
> defines can be done in ANT, asconfigc, config.xml
>
> Then in AS3 or MXML
>
> /**
> * ROYALE VERSION NUMBER
> */
> private static var _royaleVersion :String = BUILD::royaleVersion;
>
> So now you can use in any place you want
>
> HTH
>
> Carlos
>
>
--
Carlos Rovira
http://about.me/carlosrovira
RE: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
Lol, I can't seem to explain it properly. Take maven/ant/config files out of
the equation it doesn't matter for this example. This has to do with getting
some identifying information into the official SDK releases. We don't want to
pass variables as an SDK user. We want the official SDK to already come
packaged with a version number or a build number or a build date...
Here's the scenario that I would love to see happen:
1. SDK user downloads official Royale SDK release and never modifies it.
2. SDK User compiles their app using official SDK and references an official
SDK property that contains the SDK identifier already built in it. Meaning I
should be able to code complete off of the SDK and find something that already
exists and could return me an official identifier.
-Mark K
-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org]
Sent: Monday, April 29, 2019 1:14 PM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale version
to 1.0)
ok,
we do the following in maven for other needs so this will be valid for you
too:
in your maven properties.
0.9.6-OR-WHATEVER
org.apache.royale.compiler
royale-maven-plugin
true
...
BUILD::royaleVersion
'"${royale.framework.version}"'
...
...
defines can be done in ANT, asconfigc, config.xml
Then in AS3 or MXML
/**
* ROYALE VERSION NUMBER
*/
private static var _royaleVersion :String = BUILD::royaleVersion;
So now you can use in any place you want
HTH
Carlos
