In this particular case, merging fixes made on branches are enough IMO, no needs to merge back the entire release, I guess it should be a painful job sorting out what to keep or not otherwise.
-----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : jeudi 5 septembre 2013 18:48 À : dev@flex.apache.org Objet : Re: Nighly builds and releases Maybe I'm not understanding the diagram on their page. To me there is a line back from release branch to develop. It shouldn't have anything to do with hotfixes, just bug fixes found and fixed after the release branch is cut. I think the recommended practice when you have a release branch is to fix bugs in the release branch and merge back to develop as I think the diagram also shows. If you merge the other way you run the risk of picking up a develop branch change you didn't intend to pick up. So, I think we will always need to merge back. -Alex On 9/5/13 9:41 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote: >The only thing making this model merging back the release branch to the >dev one is they allow hotfixing on the release branch, so, yes, if they >are some, we need to merge them back but here at Apache Flex we don't >have this emergency to deliver, so, the bugs can be fixed on the dev >branch and another RC can be done. > >Not having hotfixes on the release branch makes the merge back useless >because there nothing left to, so, why do it and then change the build >number ? > >Instead, because we haven't this need to merge back as soon as we fix >the bugs on the dev branch only, we could simply let the dev branch >unmerged as it represents already what is released and the build >version will keep its 0 value unchanged too. > >-----Message d'origine----- >De : Alex Harui [mailto:aha...@adobe.com] Envoyé : jeudi 5 septembre >2013 18:14 À : dev@flex.apache.org Objet : Re: Nighly builds and >releases > > > >On 9/5/13 3:23 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote: > >>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 ? >IMO, we just have to decide that's what we want to do. > >Note that the Git Branching Model does show release branches merged >back to develop. It mentions that there is often a merge conflict with >the version number file but doesn't explicitly say what to do about it. >We can try leaving the version number unchanged at 0 in the develop >branch and after a release branch merge changes it, set it back to 0. > >-Alex >
