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" <bows...@gmail.com> 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 <f...@adobe.com> wrote: >> Bumping this thread. I'd like Joe to clarify as well. >> >> On 12/20/12 12:26 PM, "Brian LeRoux" <b...@brian.io> 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 <bows...@gmail.com> 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 <b...@brian.io> 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 <bows...@gmail.com> >>>>>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 <mmo...@chromium.org> >>>>>>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 >>>>>>><agri...@chromium.org> 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 >>>>>>>><cmarc...@gmail.com> >>>>>>>>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 >>>>>>>> > >>>>>>>> >>
