cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: too long to package a release?
Date Fri, 11 Jan 2013 15:32:23 GMT
Maybe I'm being coloured by the Chrome channels, but it seems to me that we
would be doing our "development" of the next release in "dev", rather than
unstable, and that bleeding edge Cordova users wanting the latest features
with no outright breakages but with higher possibility of bugs should use
"unstable". But I'm not sure how and when changes would move from one to
the other, whichever way around the names go. I'm imagining the flow would
be:
Feature branches   ---ready to push-->   my "dev" (your "unstable")
---release candidate-->   my "unstable" (your "dev")   ---release-->
 stable, tagged.

Are we going to have branches for each minor release (ie. 2.3, 2.4) so that
we can do point releases on them? Or would those be created only as
necessary when we needed a point release?


On Thu, Jan 10, 2013 at 9:05 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> I'm not clear on the difference between dev and unstable. If something is
> so shaky that we're considering not putting it in the next release, then
> I'd think that would go on a named feature branch (e.g. array_buffers).
>
> Unless... is the purpose of dev to be where we put together a release
> candidate? If so, maybe a better name would be "staging"
>
>
> On Thu, Jan 10, 2013 at 8:13 PM, Filip Maj <fil@adobe.com> wrote:
>
> > On 1/10/13 5:07 PM, "Brian LeRoux" <b@brian.io> wrote:
> >
> > >Thank you. I lean to agreement w/ Andrew that more meaningful pull
> > >reqs are better and having named branches for what they do makes
> > >sense. Also agree that tags are for points in time---but I take no
> > >exception to a branch for those as well for dev purposes.
> > >
> > >Let me try to capture the conversation to this point:
> > >
> > >Branches:
> > >- Master gets deleted. We want meaningful pull requests and this will
> > >force folks to pick a branch to dev against.
> > >- Stable: This is stable and frozen on the last tagged release.
> > >- Dev: The next release to be tagged. Feature branches merged from
> > >master when confident. This should build cleanly.
> >
> > ^^ merged from master?
> >
> > >- Unstable: the current working branch. Feature branches merged as
> > >needed for collaboration. No guarantee it builds.
> > >
> > >Tags:
> > >- Happen on the Stable branch.
> > >
> > >Workflow
> > >- Everyone works from local feature branch rebasing and committing to
> > >Unstable as neccessary.
> > >- When that feature branch is considered good enough, it is merged into
> > >Dev.
> > >- On release date whatever is Dev is rebased to Stable. Tagged.
> Released.
> > >
> > >Thoughts?
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message