Once we have 0.7.2 out, master will be the best place to work from. if we can keep disciplined about releases, the stable branch will only get updated with bug fixes or when stabilizing for a release.
I'll push up what I have. We're doing a deploy today at work, so I'm a bit behind. Probably won't happen until I get home. -dave On Mar 16, 2010, at 8:32 PM, Kevin LaCoste wrote: > On Tue, Mar 16, 2010 at 7:32 PM, Dave Grijalva <[email protected]> wrote: > > I'm keeping a local branch of patches that have been submitted to the list so > I don't lose track of them. should i push that up for review? does anybody > object to my just applying small changes like this and the prefs window > change? > > Actually, could you push this branch to GitHub? > > I was thinking along these lines with my previous comments on our workflow. > I'd like to see a branch that represents the current beta. Currently you have > 'master' and 'stable'. Either 'stable' could be tagged and the accepted > patches applied directly to it or we could have a 'beta' branch that receives > all patches and is merged with 'stable' when preparing to deliver the actual > release. > > From a contributors point of view, I think making 'master' our beta release > branch makes sense because someone cloning the project to work on something > is automatically tracking 'master' and the current beta source is probably > the best place for them to start if they want their patch to apply cleanly. > I'm not sure if I'm explaining this well so let me know if it's unclear. > > This would also allow me to see when my patches have been applied at which > point I could update my local 'master', dump the now incorporated topic > branches and rebase any work in progress on the current beta. > > If there is a preferred way of doing this I'm open to that too. I'd just like > to be clear on the best practices so I don't waste too much time rebasing > here and merging there because I was working from the wrong starting point. > > Kevin >
