Hi, Have you considered using the git flow workflow [1]? The idea is that you keep one branch (probably master) always "ready" for release. Then you have an unstable/staging branch called develop. All significant development is done on feature branches. I've found it to be quite nice in my own projects, although admittedly I don't have as many developers as Blender does.
Cheers, Alex [1] https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow On 7 Mar 2015 02:12, "Sergey Sharybin" <sergey....@gmail.com> wrote: > I would say: > > - Being able to filter in dev.b.o is omsething we must have. I've created a > quick patch to filter differencial revisions by project [1]. It was > rejected by upstream because phabricator team wants to have general way to > filter all objects which depends on project without having duplicated code > all over the place [2]. > > It'll take some time still i think, but meanwhile i don't see anything bad > in applying D11999 for our installation for until generic filtering is > implemented in an upstream. Likely some latest updates from upstream allows > to get rid of other hacks in our copy :) > > - I still think we should allow having staging-PATCH branches for > non-trivial changes at least. WOuld be kinda temp- but we'll know those > branches are subject to be merged sooner when the git is open. > > [1] https://secure.phabricator.com/D11999 > [2] https://secure.phabricator.com/T5595 > > On Fri, Mar 6, 2015 at 7:46 PM, Campbell Barton <ideasma...@gmail.com> > wrote: > > > @Gaia, > > Users like to use the *best* version of Blender (who can blame them!) > > if there is a version with 3+ interesting improvements which will be > > in the next release. I'm sure they'll use it, build on graphicall... > > etc. > > Of course anyone can make some patches version of Blender, but if we > > have a lot of users running it, it means we get issues with file > > versioning, and generally less users running master. > > And as I said before, more developers building the staging branch, > > less time finishing up master, more time moving onto the next version > > before we released this one. > > > > @Julien, > > Right - there is a `blender-next` project, but no good way to collect > > all diff's and tasks associated with it. This looks like it may be > > getting implemented (Sergey can post on this topic since he's > > investigating), even in this case it could be good to have > > feature-branches for non-trivial patches so we get to apply the patch > > and make any minor changes needed, which we would normally do before > > going into master. > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers