After running sdk/ant, git status report only " flex-sdk-description.xml" as modified file, that's 5 months or so I didn't have a look in the SDK, could you tell me what should be done in order the build number be created only on the release build envisioning what impact it could introduce ?
-Fred -----Message d'origine----- De : Frédéric THOMAS [mailto:webdoubl...@hotmail.com] Envoyé : jeudi 5 septembre 2013 11:47 À : dev@flex.apache.org Objet : RE: Nighly builds and releases Sorry for the delay, I was reading this before to go to sleep, it was more than 5am so, I answer only now. > It mostly likely be fixed on the release branch and merged back to > develop when done, but fixing on develop, testing (see CI above) and then merging into release may also be an option. You're right and that's the good option IMO, I mean not hotfixing on the release branch, usually, hotfixes (done on the release branch as opposed as the bugfixes done on the dev branch) are done because there is a pressure to deliver quickly a new version to clients, it is the case in enterprises but not here at Apache Flex, so, there is no reasons to hotfix, the counterpart for enterprises, of doing hotfixing is they have to merge them back to the dev branch. So, because we don't have the pressure to deliver quickly, we can fix RC bugs on the dev branch at the cost of having to launch another release once fixed and ready. Doing such, we don't have to merge back and the release process brings to the release branch only what it is originally done for, the creation of a build number which is no more merge back to the dev branch. As reference, the following line are taken from http://nvie.com/posts/a-successful-git-branching-model/ " Release branches support preparation of a new production release. They allow for last-minute dotting of is and crossing ts. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release." Does this process, not allowing to hotfixes on RC and thus, not having to merge back, look less error prone and less harder for now ? -Fred -----Message d'origine----- De : Justin Mclean [mailto:jus...@classsoftware.com] Envoyé : jeudi 5 septembre 2013 05:10 À : dev@flex.apache.org Objet : Re: Nighly builds and releases Hi, > That's here there is something I don't know, what should be merged > back to the develop branch ? Changes would be made in the release branch and merged into develop, otherwise the two branches would diverge and develop would no longer be a representation of the last release. All of the CI runs off the develop branch so it's best if that is as close to release as possible - which is why last time we released we merged into develop several times. > We haven't got hotfixes and if something goes wrong with the RC, it is > fixed on the dev branch and another RC is done, right ? It mostly likely be fixed on the release branch and merged back to develop when done, but fixing on develop, testing (see CI above) and then merging into release may also be an option. Justin
