On Thu, Dec 20, 2012 at 05:48:13AM +0100, deadalnix wrote: > On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips wrote: > >On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix wrote: > > > >>master : used as a base for development. New feature are merged > >>here. > >>staging : used to provide a view of what the next version will > >>look like. Regular snapshot of that branch are made so public > >>can use the last features. > >>version : used to contain a version that will have a support for > >>an extended period of time. [...] > >From the sound of it this request is pulled into master. We > >continue to pull many of these changes in. How do we decide they > >should be placed into staging, when we pull them into master?. If > >we wait for some 'magic time' how do we pull it into staging, does > >that mean we now cherry pick commits of master?
In my mind, after a release, the contents of staging are updated to be exactly the same as master. This can be done either via a merge, or simply deleting the current staging and making a new one by branching from master. > >Another issue is it sounds like master becomes a "phantom" branch. > >At no point in time would master resemble what is released. I see > >this as a problem because it is the branch people are developing off > >of, it means nothing to test in master as staging has the actual > >state that will be released. > > That is very true. With the given modification master and stagging > become redundant with one another. Why not get rid of stagging ? No, staging does not receive new features except immediately after release. But it will get bugfixes that do not introduce new things. Example timeline: - time=0: we just made a release, so staging := master. - time=1: a crash bug is discovered in master. Walter checks in a fix. Fix is propagated to staging because it doesn't introduce new things, only fixes existing problems. - time=2: Walter decides to merge UDA implementation into master (for example). Staging does NOT get UDA merged in, because UDA is new. - time=3: more bugs are found in master. Fixes are checked in. Fixes get propagated to staging. - time=4: a UDA bug is fixed. Fix is NOT propagated to staging, because staging doesn't have UDA (yet). - time=5: we decide that it's time to release. So: - we tag a release on current staging - we merge master into staging, so now staging gets UDA - time=6: Walter adds HalfFloat to master. HalfFloat is NOT propagated to staging, because it's new. - time=7: users running staging find a nasty design flaw in UDA. Walter makes a (breaking) fix in master, and the fix is propagated to staging, because UDA is already in staging. - time=8: Walter finds bugs in HalfFloat. Fixes are checked into master, but NOT staging. - time=9: Walter adds more new features to master. These are NOT propagated to staging, because they're new. - time=10: it is decided that UDA design is stable now, and we're ready for release. So: - we tag a new release on current staging - we merge master into staging, now staging gets HalfFloat. - etc. Hopefully this makes it clearer what we're trying to achieve. T -- Arise, you prisoners of Windows Arise, you slaves of Redmond, Wash, The day and hour soon are coming When all the IT folks say "Gosh!" It isn't from a clever lawsuit That Windowsland will finally fall, But thousands writing open source code Like mice who nibble through a wall. -- The Linux-nationale by Greg Baker