Alena, I think this is a matter of semantics. If you call the latest version that got through the CI a pre-release and add them as releases in the git-flow way of working on master you've got what you envision.
In spite of my mail this morning I am not a warrior (though I like the compliment, Rohit) of gitflow but I feel that it fits whatever we need so far. I have read no contradiction to that so far. The only real change to our present way of working , given that we will use support branches, is that we don't build releases on the basis of cherry-picks anymore, which is not a very big change. Other then that, naming is all that is left. Maybe I lost view on the obstacles and objections and am being short sighted here, please advice, Daan On Wed, Aug 6, 2014 at 9:59 PM, Alena Prokharchyk <alena.prokharc...@citrix.com> wrote: > > > On 8/6/14, 12:52 PM, "Erik Weber" <terbol...@gmail.com> wrote: > >>On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk < >>alena.prokharc...@citrix.com> wrote: >> >>> Agree with you, Rohit. The changes to the git model we use, are needed >>> indeed. But we should address only the problems that CS faces, and the >>> main problem - quality control. The proposal should be limited just to >>>the >>> changes that are really needed for the CS, and that will work with the >>> current CS model (minor maintenance releases support is a part of it) >>> >>> >> >>Theoretically you don't really have to change anything other than merging >>instead of cherry picking. >>That is the main issue from a release perspective. >> >>But I still think there are good reasons to do so; >> >>1) using a well known way of handling code/releases instantly tells new >>contributors / committers how we work. add to the fact that there exists >>tools to help doing this correctly is a bonus. >>2) having a known stable (atleast in theory) release as master is good >>practice. although not many users will be running from git, i still >>consider it to be good practice. >>3) there is a huge belief in this thread/discussion that as long as >>something passes CI / BVT it is considered stable. The fact is that it is >>not. Take the recent 4.4 release as a good example, where a new install >>was >>not working at all at the point of release. Now, this is more a CI / test >>coverage issue than git workflow issue, but i find it weird to use as an >>argument for not improving the workflow. >> >>-- >>Erik > > I¹m not arguing against keeping master release stable; I advocate for it. > But we can¹t adopt git workflow way of keeping master branch to be a > reflection of the latest release branch. It will not work with our way of > handling maintenance releases for multiple versions of CS - see another > thread. > > Instead, master branch should reflect the latest code that passed the CI > test (the code merged from *develop after CI passes). The release branches > should be cut from stable master branch - it will ensure that we won¹t > face last minute blockers as for 4.4, because master IS a stable branch. > And yes, we should do merges instead of cherry picking. > > > >> > -- Daan
