flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric THOMAS <webdoubl...@hotmail.com>
Subject RE: Nighly builds and releases
Date Thu, 05 Sep 2013 10:23:05 GMT
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:webdoublefx@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 i’s and crossing t’s. 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:justin@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

Mime
View raw message