Ok, tell me what files you want to merge, I'll do that tomorrow when I wake
up, it's too now here 4:10.
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Tuesday, April 16, 2013 4:02 AM
To: dev@flex.apache.org
Subject: Re: Git merge of README and RELEASE_NOTES
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
