Andrew beat me to it. I don't see how feature branches can be practical. We
would have to keep track of all the feature branches on the server, and
their current merged state.
I think it makes sense for all new commits to go into unstable, whether
they be urgent bug fixes or new features or whatever. If the bug fix is
needed for a point release, it can be cherrypicked from unstable to the
point release's branch (skipping the others canonical branches), and then
the fix will be in the next {merge to next, merge to stable, full release}
as well, with no special effort.
As long as the flow always goes unstable -> next -> stable, there are no
problems. Cherrypicking into point release branches is safe, since those
are never merged in and no canonical branches are ever merged to them (or
else they wouldn't actually be point releases). There are no cycles in this
graph.
On Mon, Jan 14, 2013 at 5:18 PM, Andrew Grieve <agri...@chromium.org> wrote:
> Could you elaborate on what the workflow would be if we merged only from
> Feature branches?
>
> On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > So, what if Canonical branches only received merges from Feature
> > branches...?
> >
> > On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <agri...@chromium.org>
> > wrote:
> > > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <f...@adobe.com> wrote:
> > >
> > >>
> > >> >But do Canonical branches merge into each other? I'm thinking no.
> > >>
> > >> My understanding:
> > >>
> > >> - work goes into feature branches
> > >> - when contributor(s) deem feature is ready, merge into Unstable,
> which
> > >> then gets vetted (test!!!!!)
> > >> - at some point unstable merges into Next
> > >> - when tagging, we merge Next into Stable and tag
> > >>
> > >
> > > That's my understanding as well.
> > >
> > > The "At some point" part would be when we say "hey, let's start working
> > on
> > > cutting a release", which should align with the wiki's
> > > RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
> > > targeted 2.3 for November, whoops!).
> > >
> > >
> > >>
> > >> Would be different for bug fixes or other maintenance-type commits
> too,
> > >> ya? Those would be directly into Next.
> > >>
> > > It might cause headaches to commit bug-fixes into Next when it comes
> time
> > > to merge Unstable -> Next.
> > >
> > >
> > >>
> > >> Finally, what about hot fixes / patch releases? Branch off the tag in
> > >> Stable and put hot patch work into there?
> > >>
> > > Agree. I think the flow here should be to commit change to Unstable and
> > > then cherry-pick it into a branch off the tag (when feasible).
> >
>
