HI, > if you have files with conflicts you want to merge, you will have to go by an > intermediary branch
This is almost always going to be the case with a release as it take time to vote on and create serval release candidates while develop work continues on in develop. > apparently the RELEASE_NOTES README are the same, you can check that running > git diff develop..release4.9 RELEASE_NOTES Both the README and RELEASE_NOTES are not the same. The develop RELEASE_NOTES still refer to incubator when the 4.9 branch doesn't. The README's differ by a significant amount. > And for the rest, it comes from what I just explained Then why is the merge of both the README and RELEASE_NOTES incorrect? The procedure as you describe doesn't work and would overwrite more recent changes. For README for instance it show that this will change: + Apache Flex 4.9.1 is a minor update to Apache Flex 4.9. That's correct. But also show this will change: -Getting the latest sources via git +Getting the latest sources via Subversion And this: - http://airdownload.adobe.com/air/mac/download/3.5/AdobeAIRSDK.tbz2 + http://airdownload.adobe.com/air/mac/download/3.4/AdobeAIRSDK.tbz2 And this: - This version of Apache Flex was certified for use with AIR 3.5, and should + This version of Apache Flex was certified for use with AIR 3.4, and should be compatible with other versions of AIR newer than 3.1. However it hasn't - been tested on AIR 3.2, 3.3, 3.6 or 3.7. + been tested on AIR 3.2, 3.3 or 3.5. And this: - is compatible with versions 10.2 through 11.7. It has been tested with versions 11.1 + is compatible with versions 10.2 through 11.5. It has been tested with versions 11.1 And many other similar changes. It looks like it's reverting all changes we actually need - this should not happen! So I ask again why did git do this and more importantly what is the correct process so these changes are not lost. Thanks, Justin
