cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: Plugins Release today
Date Tue, 03 Dec 2013 20:29:06 GMT
On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland <iclelland@google.com> wrote:

> On Tue, Dec 3, 2013 at 3:00 PM, Steven Gill <stevengill97@gmail.com>
> wrote:
>
> > Thanks for filling me in on the state!
> >
> > Is it just File that isn't ready? File-transfer is good?
> >
>
> I'll see if I can run a test on iOS with the dev branch of file-transfer,
> and the master branch of file -- if that still passes, I'll OK releasing
> file-transfer. (If not, I'll fix it until it does :) )
>
> Sounds good!

>
> > I don't think it is worth it to rip out the code from dev, especially if
> it
> > is almost ready. I will hold off releasing file with this plugins
> release.
> > We can aim to get a new version of file out next week after it has been
> > tested (especially with plugins that depend on it). Of course, if you
> > strongly feel some of those other commits on file should get out asap,
> then
> > lets move forward with ripping out so it can be released.
> >
> > In the future we should all try to work off branches and push code onto
> dev
> > that is ready to be pushed to master. We should use dev as master since
> our
> > master branch is just for releasing.
>
>
> Dev becomes a staging branch, essentially; and all actual dev work happens
> on branches. That sounds like a more sane way to do it. The only reason I
> had it on dev in the first place was to be able to test with buildbot --
> I'd love to have a way to run those branches through the CI server before
> merging them into dev/staging/master.


Good point. Maybe we standardize a third branch (ducks for cover) that the
CI server also tests and can be used for breaking dev work. This way dev is
used for staging and only has code that can be released. I'm afraid that
this just adds more complexity to plugins though and I am not a fan of
adding more complexity.


>
 Ian
>
>
>
> > Still confusing at times. It will be
> > nice once we can get away from this dev-master setup we have. I'm sure
> many
> > of us have pushed code to dev that isn't in a sate to be released. Maybe
> > this point/process should get added to our wiki? Not sure where the best
> > place for it would be.
> >
> >
> >
> >
> > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland <iclelland@google.com>
> > wrote:
> >
> > > Hey Steven,
> > >
> > > File is close to being ready, but I haven't merged in my Android code
> > yet,
> > > and I want to add some more tests, given how critical the plugin is.
> I'm
> > > not comfortable with it going to master yet. If you want, I can pull it
> > out
> > > of dev and put it on another branch. (There have been some other
> commits,
> > > so we could also create a new branch without those commits, and merge
> > > *that* into master instead)
> > >
> > > Let me know how you want to handle it, I'll help out any way I can.
> > >
> > > Ian
> > >
> > >
> > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill <stevengill97@gmail.com>
> > > wrote:
> > >
> > > > Any plugin issues I should know about before releasing today?
> > > >
> > > > Last I heard file and file-transfer dev branches aren't ready to be
> > > merged
> > > > into master. Has this changed? Ian?
> > > >
> > > > Plugin issues that are still being reviewed/worked on:
> > > > https://issues.apache.org/jira/browse/CB-5525
> > > > https://issues.apache.org/jira/browse/CB-5531
> > > > https://issues.apache.org/jira/browse/CB-5532
> > > > https://issues.apache.org/jira/browse/CB-5430
> > > > https://issues.apache.org/jira/browse/CB-5504
> > > > https://issues.apache.org/jira/browse/CB-5505
> > > >
> > > > I can wait until later in the day to release if some of these are
> > getting
> > > > resolve today. I know Jesse is looking at the windows ones.
> > > >
> > > > We can also just do another plugin release next week (or post
> holidays)
> > > > once some of these land.
> > > >
> > >
> >
>

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