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 >>>>>> > >>>>>>
