On 2/24/14 10:11 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi, > >> This still seems funny to me. Why should a generated file be in version >> control? > >So you can see that it has changed and more importantly what's changed >inside it. That way you can instantly see that a release candidate is >broken without have to run extra tests (manual or otherwise). But the changes you are hoping to track are really results of properly changing something else that generates the version files? > >This has already caused one RC to be scrapped and it was only luck I >managed to pick up the issue(s) with this one. > >Also from a quick look both 4.10 and 4.11 releases - both have similar >issues and no one noticed. eg look at the Version.as file in both or do a >mxmlc -version Yeah, so a test would parse the package (apache-flex-sdk-4.12.0), pull out the 4.12 and scan Version.as and that file in MXMLC and other places. And if we put that in the release scripts it would blow up before you cut the RC. I'm not the RM, but it seems to me that even if you put these files in version control it still won't catch the fact that the RM forgot to update those files. It just helps you prove after you figure that out that nobody updated those files. > >If it's in a release package there probably an Apache obligation to have >it under version control as well - although that may be a bit of a grey >area if it a generated file. In theory, a file generated by the build script should not be in the repo or the source package since it gets generated by the build script. -Alex
