I don't like this approach. The replaced tag will surely get submitted.
I really don't understand why so much attention has been devoted to this
today. There are so many other things to do.
Carol
On 2/24/12 5 :19PM, "Om" <bigosma...@gmail.com> wrote:
>I like this approach. This is how we bake in application version numbers,
>build timestamp, etc. while compiling release builds of Flex apps we ship.
>
>
>
>> Minor issue with this is that now the Version.as files are out of sync
>> with SVN, could accidentally be checked back in with wrong version
>>numbers
>> or the like.
>>
>> I guess there's the more philosophical question of do we really want
>>ANT
>> scripts that modify the source code?
>>
>
>We can revert Version.as to its original state after compiling or just not
>check in the changed Version.as. A carefully constructed build script
>should do the trick. This way we don't really care if Ant is making
>changes to the source code.
>
>Om
>
>On Fri, Feb 24, 2012 at 2:11 PM, Justin Mclean
><jus...@classsoftware.com>wrote:
>
>> Hi,
>>
>> ANT can do this quite easily.
>>
>> If we change all Version.as files to be like so:
>> mx_internal static const VERSION:String = "@release@";
>>
>> Then this target will inject the version number into all Version.as
>>files:
>> <target name="setFlexSDKVersion">
>> <replace dir="${basedir}" includes="**/Version.as"
>>token="@release@"
>> value="${release.version}.${build.number}" />
>> </target>
>>
>> We have these currently in the build file:
>> <property name="release.version" value="4.6.0"/>
>> <property name="build.number" value="0"/>
>>
>> So that would replace every occurrence of "@release@" with "4.6.0.0".
>>
>> Minor issue with this is that now the Version.as files are out of sync
>> with SVN, could accidentally be checked back in with wrong version
>>numbers
>> or the like.
>>
>> I guess there's the more philosophical question of do we really want
>>ANT
>> scripts that modify the source code?
>>
>> Justin
>>
>>
>>
>>
