cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: too long to package a release?
Date Fri, 11 Jan 2013 18:55:55 GMT
I think we all agree on the general flow of feature branch -> "staging" ->
merge into "master" + tag.

Ripple uses "next" as the label for the branch with all stuff going into
the next release. I like this approach.

On 1/11/13 7:48 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:

>I don't think there's any advantage to creating them ahead of time, so we
>might as well not bother.
>
>
>On Fri, Jan 11, 2013 at 10:32 AM, Braden Shepherdson
><braden@chromium.org>wrote:
>
>> 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
View raw message