A hot fix is usually branched off of master, tested, merged and released. We then rebase / merge the hotfix up into next.
On Wed, Jan 2, 2013 at 4:51 PM, Michal Mocny <[email protected]> wrote: > Also: while I personally prefer master to be the dev channel, I will say > that I do like Gord's suggestion of how its done in ripple in that the name > of the dev branch is 'next' and not '2.3.0' so that your dev setup doesn't > need to change every month. > > Gord: how do you deal with bugfixes/point releases? Do you fix in feature > branch, merge into next, and then cherry-pick/merge just that fix into > master before doing a major release? Or, do you just offer bugfixes via > 'next'? > > > On Wed, Jan 2, 2013 at 4:45 PM, Michal Mocny <[email protected]> wrote: > > > I don't have much weight here, but personally I feel that this seems > > backwards. > > > > With this proposal (if I understand it), when you do a fresh checkout of > > the codebase, instead of sitting on the bleeding edge, you would be > sitting > > at a "stable" release which is conceptually read-only for most > contributors > > (writes happen in the form of batch "releases" which itself would just be > > some git-fu to rebase master). > > > > I am happy enough to have features be worked on in branches etc, I just > > think that it should be flipped and the stable release be the branch and > > dev to be on master. > > > > > > As a separate issue, I would suggest not using branches to "name" point > > releases, but just tag them. If you have a 2.3.0 release, and you need > to > > fix a bug in 2.3.1, those should not become two logically separate code > > branches with independent dev, but rather they are a logically single > > timeline with many names for each historically significant commit, right? > > Thats what tags are for (http://git-scm.com/book/en/Git-Basics-Tagging > ). > > > > -Michal > > > > > > On Wed, Jan 2, 2013 at 3:05 PM, Gord Tanner <[email protected]> wrote: > > > >> This is what we have done in ripple (and webworks) > >> > >> master - always stable current shipping code > >> next - always 'stable' next release. Expectation that code has been > tested > >> / run before merged into this branch. > >> feature branches - branched off of next and merged into next when > stable / > >> done. Not expected to be stable or runnable until merge time. > >> > >> > >> > >> On Wed, Jan 2, 2013 at 2:32 PM, Filip Maj <[email protected]> wrote: > >> > >> > Am I correct when I say that, with this approach, master becomes a > >> series > >> > of merge commits coming from dev, then ? > >> > > >> > A couple questions to follow up: > >> > > >> > - "features get forked from stable" - forked from master, yes? > >> > - "features, when ready, tested against dev branch" - what does this > >> mean? > >> > Does this mean, you would merge feature branch into dev branch > (locally) > >> > then run tests to make sure things work? > >> > > >> > On 1/2/13 11:19 AM, "Joe Bowser" <[email protected]> wrote: > >> > > >> > >OK, Let's rethink this: > >> > > > >> > >After talking with Brian on the 21st, I think we agree on this: > >> > > > >> > > * Master remains stable and sits at the most recent released code > >> > >(i.e. 2.3.0 once we get 2.3.0 done) (Stable Channel) > >> > > * Dev happens on branches for the releases (i.e. 2.4.0) (Dev > Channel) > >> > > * In the case of a point release, dev happens in the branch of the > >> > >major release (i.e. 2.3.1 would happen in the 2.3.0 branch, not > >> > >master) (Testing Channel) > >> > > * Features get forked on stable then once the feature is ready, > >> > >tested against the dev branch. If they work with stable, they SHOULD > >> > >work with 2.4.0. If they don't, the tickets get added to 2.4.0 to > >> > >make it work with that release. That way things are more predictable > >> > >as far as new features are concerned. (You will burn your face > >> > >channel). > >> > > > >> > >Does that make sense? Working on master for things causes us pain and > >> > >we should use git conventions to make it simpler for people who > expect > >> > >our master to work all the time. I don't think this will speed up > the > >> > >release as much as automating tagging of RCs so that when the JS is > >> > >tagged, everything else is tagged. The week it takes to tag an RC is > >> > >way too long. > >> > > > >> > > > >> > >On Wed, Jan 2, 2013 at 11:08 AM, Filip Maj <[email protected]> wrote: > >> > >> Bumping this thread. I'd like Joe to clarify as well. > >> > >> > >> > >> On 12/20/12 12:26 PM, "Brian LeRoux" <[email protected]> wrote: > >> > >> > >> > >>>Ok, I want to understand this, let me take a stab. > >> > >>> > >> > >>>You describe three long-lived branches like this: > >> > >>> > >> > >>>- Master: This is stable and frozen on the last tagged release. > >> > >>>- Dev: the next release to be tagged. Feature branches merged from > >> > >>>master when confident. > >> > >>>- Unstable: the current working branch for a particular tag. > Feature > >> > >>>branches merged as needed for collaboration. > >> > >>> > >> > >>>Everyone works from local feature branch rebasing and committing to > >> > >>>master. When that feature branch is considered good enough, it is > >> > >>>merged into dev, and work continues. Whatever date we happen to > pick > >> > >>>for a release that is what dev becomes, we tag, and move that sha > to > >> > >>>stable if its not an RC. > >> > >>> > >> > >>>? > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>>On Thu, Dec 20, 2012 at 10:52 AM, Joe Bowser <[email protected]> > >> wrote: > >> > >>>> I'm OK with this, but I think your example is off: > >> > >>>> > >> > >>>> Where n is the current released piece of the software: > >> > >>>> > >> > >>>> n.x.x = Stable > >> > >>>> n+1.x.x = Dev > >> > >>>> master = Unstable, can have things merged in from feature > branches > >> > >>>> > >> > >>>> This fully uncouples features from release planning, which is > good > >> > >>>> because it means the release will land in the version when it's > >> ready, > >> > >>>> and not for any other reason. I also propose that we keep using > >> the > >> > >>>> same RC tags and that for a final release we tag it x.x.xFinal. > We > >> > >>>> still need to tag an RC and re-tag it. > >> > >>>> > >> > >>>> Release Process: > >> > >>>> 1. Tag the dev tree > >> > >>>> 2. merge the dev tree back into master > >> > >>>> 3. Create 2.5.0 branch > >> > >>>> 4. File issues from 2.5.0 in JIRA > >> > >>>> > >> > >>>> I also propose that we automate the tagging. If an RC is broken, > >> we > >> > >>>> just cut another RC. A lot of our retagging is done to get > around > >> the > >> > >>>> pain of having to do another RC. The biggest part of the delay > is > >> > >>>> waiting for every single platform maintainer to tag their > platform > >> > >>>> after the JS was tagged. For example, I tagged rc2 for the JS > and > >> for > >> > >>>> Android on Monday last week from my hotel room, and the release > >> wasn't > >> > >>>> fully tagged until this week. I'm fine with RCs going up to 10 > as > >> > >>>> long as we can release early, release often and release when we > >> want > >> > >>>> to and not run out of time and have to delay. > >> > >>>> > >> > >>>> On Thu, Dec 20, 2012 at 10:33 AM, Brian LeRoux <[email protected]> > wrote: > >> > >>>>> Truth. Though lets not get hung up on the past and just focus on > >> the > >> > >>>>> present. We've done a really good job getting where we are. > >> > >>>>> > >> > >>>>> So, Joe, are you saying you like the idea of three long lived > >> > >>>>>branches > >> > >>>>> and merges happen from local feature branches? > >> > >>>>> > >> > >>>>> > >> > >>>>> On Thu, Dec 20, 2012 at 10:22 AM, Joe Bowser <[email protected] > > > >> > >>>>>wrote: > >> > >>>>>> We are totally doing something wrong with the way that we do > >> > >>>>>>releases. > >> > >>>>>> I personally think that we're not using git right, and here's > >> why: > >> > >>>>>> > >> > >>>>>> Currently, when we do a release, we tag the RC, and we test the > >> RC. > >> > >>>>>> There's nothing preventing us from putting things after that > tag > >> and > >> > >>>>>> if we don't want to those things in the release branching off > >> that > >> > >>>>>> tag. We've done it before and other than the problem with > CoHo, > >> it > >> > >>>>>> worked really well. I propose that instead of tagging the > >> release, > >> > >>>>>>we > >> > >>>>>> branch when we want to do a release, and we do all the bug > fixes > >> on > >> > >>>>>> that branch. Once that branch is ready to roll, we merge it > back > >> > >>>>>>into > >> > >>>>>> master. In fact, nobody should be working on master except to > do > >> > >>>>>> merges. The way we're doing this now feels dirty and wrong. > >> > >>>>>> > >> > >>>>>> I honestly feel that this is a much faster way of working, and > >> that > >> > >>>>>> we're missing the point if we have to tell everyone to jump out > >> of > >> > >>>>>>the > >> > >>>>>> pool every time we do an RC. I know that we could be working > on > >> our > >> > >>>>>> branches, but that work is almost entirely invisible to the > rest > >> of > >> > >>>>>> the project until it's time to merge it back in, which takes > >> > >>>>>>forever. > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> On Thu, Dec 20, 2012 at 10:07 AM, Michal Mocny < > >> [email protected] > >> > > > >> > >>>>>>wrote: > >> > >>>>>>> So there is something to be said about having devs shift focus > >> from > >> > >>>>>>>dev to > >> > >>>>>>> testing during an RC. However, as the team grows, not all of > us > >> > >>>>>>>are > >> > >>>>>>>really > >> > >>>>>>> being responsible for cutting releases. Maybe that means we > >> need > >> > >>>>>>>to > >> > >>>>>>>train > >> > >>>>>>> the entire team to change current behavior, but that doesn't > >> feel > >> > >>>>>>> necessary/scalable. > >> > >>>>>>> > >> > >>>>>>> With growing external contributions, I would have to say that > a > >> > >>>>>>>code > >> > >>>>>>>freeze > >> > >>>>>>> on trunk doesn't seem to make as much sense. > >> > >>>>>>> > >> > >>>>>>> -Michal > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> On Thu, Dec 20, 2012 at 9:47 AM, Andrew Grieve > >> > >>>>>>><[email protected]> wrote: > >> > >>>>>>> > >> > >>>>>>>> I definitely think we'd get more done if we didn't have such > a > >> > >>>>>>>>long > >> > >>>>>>>> code-freeze. I'm not sure this is the same as what you were > >> > >>>>>>>>suggesting, but > >> > >>>>>>>> have a script/tool to branch all of the platforms into an rc > >> > >>>>>>>>branch. Then, > >> > >>>>>>>> each platform can fix themselves up a bit and tag their RC. > >> > >>>>>>>>Meanwhile, dev > >> > >>>>>>>> can continue to happen on edge. > >> > >>>>>>>> > >> > >>>>>>>> My main concern with our current approach is just that the > >> > >>>>>>>>code-freeze time > >> > >>>>>>>> is super long. > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> On Wed, Dec 19, 2012 at 3:36 PM, Marcel Kinard > >> > >>>>>>>><[email protected]> > >> > >>>>>>>>wrote: > >> > >>>>>>>> > >> > >>>>>>>> > One of the things that strikes me here is the difference > >> between > >> > >>>>>>>>calendar > >> > >>>>>>>> > time and effort time. (This assumes folks already concurred > >> that > >> > >>>>>>>>the rc > >> > >>>>>>>> is > >> > >>>>>>>> > ready to release.) Based on my reading of > >> > >>>>>>>>http://wiki.apache.org/** > >> > >>>>>>>> > cordova/CuttingReleases > >> > >>>>>>>><http://wiki.apache.org/cordova/CuttingReleases>there > >> > >>>>>>>> isn't a lot of effort time involved to cut a release. It > seems > >> > >>>>>>>>like > >> > >>>>>>>>a > >> > >>>>>>>> > good chunk of the calendar time is getting folks to tag > their > >> > >>>>>>>>platform. > >> > >>>>>>>> > Ideally the promotion from rc to final should take very > >> little > >> > >>>>>>>>effort > >> > >>>>>>>> time. > >> > >>>>>>>> > > >> > >>>>>>>> > What I like about the rc is that it provides a settling > >> > >>>>>>>>mechanism > >> > >>>>>>>>for the > >> > >>>>>>>> > churn to calm down, run tests across more integration, and > >> see > >> > >>>>>>>>the bigger > >> > >>>>>>>> > picture to assess release readiness. I would expect that > the > >> > >>>>>>>>promotion > >> > >>>>>>>> from > >> > >>>>>>>> > edge to rc should take a decent amount of effort time, but > >> not > >> > >>>>>>>>because of > >> > >>>>>>>> > the "cut" activities. > >> > >>>>>>>> > > >> > >>>>>>>> > So when we are at rc and don't find any surprises, why does > >> it > >> > >>>>>>>>take a > >> > >>>>>>>> week > >> > >>>>>>>> > to promote to final? If we spend a week in rc1, another > week > >> in > >> > >>>>>>>>rc2, and > >> > >>>>>>>> > another week to cut final, that leaves only 1 week in a > >> 4-week > >> > >>>>>>>>cycle for > >> > >>>>>>>> > active dev work? > >> > >>>>>>>> > > >> > >>>>>>>> > I like the ideal of a channel/stream/branch/whatever where > >> there > >> > >>>>>>>>is a > >> > >>>>>>>> > place for the rc to settle without necessarily blocking > >> commits > >> > >>>>>>>>to edge. > >> > >>>>>>>> > Where I'm going with this is that if there is an area where > >> > >>>>>>>>commits to > >> > >>>>>>>> the > >> > >>>>>>>> > rc are carefully controlled, then perhaps one person (i.e, > >> Steve > >> > >>>>>>>>G) could > >> > >>>>>>>> > cut the release for ALL platforms using scripts. This may > >> > >>>>>>>>involve > >> > >>>>>>>>that > >> > >>>>>>>> one > >> > >>>>>>>> > person tagging/branching/whatever across multiple > platforms. > >> > >>>>>>>> > > >> > >>>>>>>> > I also like putting the "how to cut" magic in each > platform. > >> > >>>>>>>>Then > >> > >>>>>>>>perhaps > >> > >>>>>>>> > a good chunk of coho is tests to make sure that the > platform > >> > >>>>>>>>magic > >> > >>>>>>>> > delivered the correct format to it. > >> > >>>>>>>> > > >> > >>>>>>>> > -- Marcel Kinard > >> > >>>>>>>> > > >> > >>>>>>>> > >> > >> > >> > > >> > > >> > > > > >
