You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Lorin Beer <lo...@gmail.com> on 2014/06/09 20:50:43 UTC
minor bump to cordova-lib
Minor bump to cordova-lib to expose a broken out package.
history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
squashed commit to master:
https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
This does not change any functionality of the modules, just the way
they are wired up. It also provides an additional package.json file to
better expose the cordova-lib submodules.
I think that qualifies as a patch, and should not require a release vote.
I will hold off on npm publish for some feedback
- Lorin
Re: minor bump to cordova-lib
Posted by Joe Bowser <bo...@gmail.com>.
And this is why we rarely release anything anymore.
On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux <b...@brian.io> wrote:
> /me slow clap
>
>
> On Mon, Jun 9, 2014 at 1:57 PM, Marvin Humphrey <ma...@rectangular.com>
> wrote:
>
>> On Mon, Jun 9, 2014 at 1:35 PM, Brian LeRoux <b...@brian.io> wrote:
>> > My understanding is that a VOTE was for ./dist and that anything npm is
>> the
>> > domain of the person publishing.
>>
>> Here's the policy:
>>
>> http://www.apache.org/dev/release#what
>>
>> What Is A Release?
>>
>> Releases are, by definition, anything that is published beyond the group
>> that owns it. In our case, that means any publication outside the group
>> of
>> people on the product dev list. If the general public is being
>> instructed to
>> download a package, then that package has been released. Each PMC must
>> obey
>> the ASF requirements on approving any release. [...]
>>
>> So it's not that packages published to npm (or any other downstream
>> distribution channel) don't require a VOTE, it's that npm packages should
>> also
>> be published to dist (and require a VOTE).
>>
>> Marvin Humphrey
>>
Re: minor bump to cordova-lib
Posted by Brian LeRoux <b...@brian.io>.
first what? A hotfix
On Jun 9, 2014 6:33 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> Marvin's email came across to me as respectful.
> Brian and Joe - your responses came across as disrespectful to me. Slow
> claps and sarcasm should probably be avoided in email.
>
> This issue has been covered at length, and the a very clear conclusion was
> made that unless policies change, anything published to npm that is
> intended for users outside of the project must first land on dist/.
>
>
> On Mon, Jun 9, 2014 at 6:38 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > Blind copy paste of URLs and blanket repeat emails are not helping
> either.
> > We can and do VOTE on artifacts.
> >
> > (And, FTR, I'm perfectly fine with the ceremony but I'd prefer we cast
> > votes as tags like we used to. A topic for the board and members to
> debate
> > to be sure.)
> >
> > Your earlier emails demonstrate well how little you understand of the
> > project. I'd recommend *actually* building Cordova *then* providing
> advice
> > about how to improve it and our release process. Seriously: it would
> help.
> > On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux <b...@brian.io> wrote:
> > > /me slow clap
> >
> > Brian, I realize that you are deeply opposed to voting on releases, and I
> > understand and respect your arguments. Were Cordova an independent
> > project, I
> > would not come to the community proposing that release voting be adopted.
> >
> > However, Cordova is at Apache and the policies are what they are. You're
> > welcome to make the case that the org should change, but to be honest I
> > doubt
> > such a change is achievable in the near term. The policy has deep roots
> --
> > a
> > good chunk of the Foundation's legal structure is built in its service.
> > And
> > so I would argue that avoiding quixotic conflicts with the Board is in
> the
> > best interest of most Cordova stakeholders.
> >
> > In the meantime, the question is how to make the best of things within
> > existing constraints. For the record, there's nothing stopping Cordova
> > from releasing on a fixed cadence.
> >
> > Marvin Humphrey
> >
>
Re: minor bump to cordova-lib
Posted by Andrew Grieve <ag...@chromium.org>.
Marvin's email came across to me as respectful.
Brian and Joe - your responses came across as disrespectful to me. Slow
claps and sarcasm should probably be avoided in email.
This issue has been covered at length, and the a very clear conclusion was
made that unless policies change, anything published to npm that is
intended for users outside of the project must first land on dist/.
On Mon, Jun 9, 2014 at 6:38 PM, Brian LeRoux <b...@brian.io> wrote:
> Blind copy paste of URLs and blanket repeat emails are not helping either.
> We can and do VOTE on artifacts.
>
> (And, FTR, I'm perfectly fine with the ceremony but I'd prefer we cast
> votes as tags like we used to. A topic for the board and members to debate
> to be sure.)
>
> Your earlier emails demonstrate well how little you understand of the
> project. I'd recommend *actually* building Cordova *then* providing advice
> about how to improve it and our release process. Seriously: it would help.
> On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux <b...@brian.io> wrote:
> > /me slow clap
>
> Brian, I realize that you are deeply opposed to voting on releases, and I
> understand and respect your arguments. Were Cordova an independent
> project, I
> would not come to the community proposing that release voting be adopted.
>
> However, Cordova is at Apache and the policies are what they are. You're
> welcome to make the case that the org should change, but to be honest I
> doubt
> such a change is achievable in the near term. The policy has deep roots --
> a
> good chunk of the Foundation's legal structure is built in its service.
> And
> so I would argue that avoiding quixotic conflicts with the Board is in the
> best interest of most Cordova stakeholders.
>
> In the meantime, the question is how to make the best of things within
> existing constraints. For the record, there's nothing stopping Cordova
> from releasing on a fixed cadence.
>
> Marvin Humphrey
>
Re: minor bump to cordova-lib
Posted by Brian LeRoux <b...@brian.io>.
Blind copy paste of URLs and blanket repeat emails are not helping either.
We can and do VOTE on artifacts.
(And, FTR, I'm perfectly fine with the ceremony but I'd prefer we cast
votes as tags like we used to. A topic for the board and members to debate
to be sure.)
Your earlier emails demonstrate well how little you understand of the
project. I'd recommend *actually* building Cordova *then* providing advice
about how to improve it and our release process. Seriously: it would help.
On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux <b...@brian.io> wrote:
> /me slow clap
Brian, I realize that you are deeply opposed to voting on releases, and I
understand and respect your arguments. Were Cordova an independent
project, I
would not come to the community proposing that release voting be adopted.
However, Cordova is at Apache and the policies are what they are. You're
welcome to make the case that the org should change, but to be honest I
doubt
such a change is achievable in the near term. The policy has deep roots --
a
good chunk of the Foundation's legal structure is built in its service. And
so I would argue that avoiding quixotic conflicts with the Board is in the
best interest of most Cordova stakeholders.
In the meantime, the question is how to make the best of things within
existing constraints. For the record, there's nothing stopping Cordova
from releasing on a fixed cadence.
Marvin Humphrey
Re: minor bump to cordova-lib
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux <b...@brian.io> wrote:
> /me slow clap
Brian, I realize that you are deeply opposed to voting on releases, and I
understand and respect your arguments. Were Cordova an independent project, I
would not come to the community proposing that release voting be adopted.
However, Cordova is at Apache and the policies are what they are. You're
welcome to make the case that the org should change, but to be honest I doubt
such a change is achievable in the near term. The policy has deep roots -- a
good chunk of the Foundation's legal structure is built in its service. And
so I would argue that avoiding quixotic conflicts with the Board is in the
best interest of most Cordova stakeholders.
In the meantime, the question is how to make the best of things within
existing constraints. For the record, there's nothing stopping Cordova
from releasing on a fixed cadence.
Marvin Humphrey
Re: minor bump to cordova-lib
Posted by Brian LeRoux <b...@brian.io>.
/me slow clap
On Mon, Jun 9, 2014 at 1:57 PM, Marvin Humphrey <ma...@rectangular.com>
wrote:
> On Mon, Jun 9, 2014 at 1:35 PM, Brian LeRoux <b...@brian.io> wrote:
> > My understanding is that a VOTE was for ./dist and that anything npm is
> the
> > domain of the person publishing.
>
> Here's the policy:
>
> http://www.apache.org/dev/release#what
>
> What Is A Release?
>
> Releases are, by definition, anything that is published beyond the group
> that owns it. In our case, that means any publication outside the group
> of
> people on the product dev list. If the general public is being
> instructed to
> download a package, then that package has been released. Each PMC must
> obey
> the ASF requirements on approving any release. [...]
>
> So it's not that packages published to npm (or any other downstream
> distribution channel) don't require a VOTE, it's that npm packages should
> also
> be published to dist (and require a VOTE).
>
> Marvin Humphrey
>
Re: minor bump to cordova-lib
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Jun 9, 2014 at 1:35 PM, Brian LeRoux <b...@brian.io> wrote:
> My understanding is that a VOTE was for ./dist and that anything npm is the
> domain of the person publishing.
Here's the policy:
http://www.apache.org/dev/release#what
What Is A Release?
Releases are, by definition, anything that is published beyond the group
that owns it. In our case, that means any publication outside the group of
people on the product dev list. If the general public is being instructed to
download a package, then that package has been released. Each PMC must obey
the ASF requirements on approving any release. [...]
So it's not that packages published to npm (or any other downstream
distribution channel) don't require a VOTE, it's that npm packages should also
be published to dist (and require a VOTE).
Marvin Humphrey
Re: minor bump to cordova-lib
Posted by Brian LeRoux <b...@brian.io>.
My understanding is that a VOTE was for ./dist and that anything npm is the
domain of the person publishing.
On Mon, Jun 9, 2014 at 1:27 PM, Steven Gill <st...@gmail.com> wrote:
> Going to have to do a vote to release to npm.
>
>
> On Mon, Jun 9, 2014 at 1:22 PM, Lorin Beer <lo...@gmail.com> wrote:
>
> > good. lord.
> >
> > On Mon, Jun 9, 2014 at 1:04 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> > > We all wish!
> > >
> > >
> > > On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer <lo...@gmail.com>
> wrote:
> > >
> > >> Michal: the root package.json is being removed. I do want to perform
> > >> an npm publish with a patch version increment, so downstream projects
> > >> can reference include by npm registry and not git url. That would
> > >> constitute a 'release' of some sort. My understanding was that bug
> > >> patches of this sort could be pushed out with minimum fuss.
> > >>
> > >>
> > >> On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >> > In particular, I thought the root of the repo wasn't supposed to be
> a
> > >> node
> > >> > package, but a bucket for multiple node packages. (ie, should not
> be
> > a
> > >> > package.json at the root).
> > >> >
> > >> > We don't vote on commits (though its nice to ask for review for big
> > hairy
> > >> > patches like this one, so thanks for that).
> > >> >
> > >> > -Michal
> > >> >
> > >> >
> > >> > On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve <agrieve@chromium.org
> >
> > >> wrote:
> > >> >
> > >> >> I think all releases require votes. Only difference is that for
> > urgent
> > >> >> releases we can have a shorter vote period.
> > >> >>
> > >> >> Looking at your commit - there's now two package.json files with
> the
> > >> same
> > >> >> name. I don't think that's allowed by npm.
> > >> >>
> > >> >> Your goal was to make configparser its own package right? Doesn't
> it
> > >> need
> > >> >> its own package.json file to be its own package?
> > >> >>
> > >> >>
> > >> >> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer <lo...@gmail.com>
> > >> wrote:
> > >> >>
> > >> >> > Minor bump to cordova-lib to expose a broken out package.
> > >> >> >
> > >> >> > history:
> > >> >> >
> > >> >>
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
> > >> >> >
> > >> >> > squashed commit to master:
> > >> >> >
> > >> >> >
> > >> >>
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
> > >> >> >
> > >> >> >
> > >> >> > This does not change any functionality of the modules, just the
> way
> > >> >> > they are wired up. It also provides an additional package.json
> > file to
> > >> >> > better expose the cordova-lib submodules.
> > >> >> >
> > >> >> >
> > >> >> > I think that qualifies as a patch, and should not require a
> release
> > >> vote.
> > >> >> >
> > >> >> > I will hold off on npm publish for some feedback
> > >> >> >
> > >> >> > - Lorin
> > >> >> >
> > >> >>
> > >>
> >
>
Re: minor bump to cordova-lib
Posted by Steven Gill <st...@gmail.com>.
Going to have to do a vote to release to npm.
On Mon, Jun 9, 2014 at 1:22 PM, Lorin Beer <lo...@gmail.com> wrote:
> good. lord.
>
> On Mon, Jun 9, 2014 at 1:04 PM, Michal Mocny <mm...@chromium.org> wrote:
> > We all wish!
> >
> >
> > On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer <lo...@gmail.com> wrote:
> >
> >> Michal: the root package.json is being removed. I do want to perform
> >> an npm publish with a patch version increment, so downstream projects
> >> can reference include by npm registry and not git url. That would
> >> constitute a 'release' of some sort. My understanding was that bug
> >> patches of this sort could be pushed out with minimum fuss.
> >>
> >>
> >> On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >> > In particular, I thought the root of the repo wasn't supposed to be a
> >> node
> >> > package, but a bucket for multiple node packages. (ie, should not be
> a
> >> > package.json at the root).
> >> >
> >> > We don't vote on commits (though its nice to ask for review for big
> hairy
> >> > patches like this one, so thanks for that).
> >> >
> >> > -Michal
> >> >
> >> >
> >> > On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve <ag...@chromium.org>
> >> wrote:
> >> >
> >> >> I think all releases require votes. Only difference is that for
> urgent
> >> >> releases we can have a shorter vote period.
> >> >>
> >> >> Looking at your commit - there's now two package.json files with the
> >> same
> >> >> name. I don't think that's allowed by npm.
> >> >>
> >> >> Your goal was to make configparser its own package right? Doesn't it
> >> need
> >> >> its own package.json file to be its own package?
> >> >>
> >> >>
> >> >> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer <lo...@gmail.com>
> >> wrote:
> >> >>
> >> >> > Minor bump to cordova-lib to expose a broken out package.
> >> >> >
> >> >> > history:
> >> >> >
> >> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
> >> >> >
> >> >> > squashed commit to master:
> >> >> >
> >> >> >
> >> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
> >> >> >
> >> >> >
> >> >> > This does not change any functionality of the modules, just the way
> >> >> > they are wired up. It also provides an additional package.json
> file to
> >> >> > better expose the cordova-lib submodules.
> >> >> >
> >> >> >
> >> >> > I think that qualifies as a patch, and should not require a release
> >> vote.
> >> >> >
> >> >> > I will hold off on npm publish for some feedback
> >> >> >
> >> >> > - Lorin
> >> >> >
> >> >>
> >>
>
Re: minor bump to cordova-lib
Posted by Lorin Beer <lo...@gmail.com>.
good. lord.
On Mon, Jun 9, 2014 at 1:04 PM, Michal Mocny <mm...@chromium.org> wrote:
> We all wish!
>
>
> On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer <lo...@gmail.com> wrote:
>
>> Michal: the root package.json is being removed. I do want to perform
>> an npm publish with a patch version increment, so downstream projects
>> can reference include by npm registry and not git url. That would
>> constitute a 'release' of some sort. My understanding was that bug
>> patches of this sort could be pushed out with minimum fuss.
>>
>>
>> On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny <mm...@chromium.org> wrote:
>> > In particular, I thought the root of the repo wasn't supposed to be a
>> node
>> > package, but a bucket for multiple node packages. (ie, should not be a
>> > package.json at the root).
>> >
>> > We don't vote on commits (though its nice to ask for review for big hairy
>> > patches like this one, so thanks for that).
>> >
>> > -Michal
>> >
>> >
>> > On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> >
>> >> I think all releases require votes. Only difference is that for urgent
>> >> releases we can have a shorter vote period.
>> >>
>> >> Looking at your commit - there's now two package.json files with the
>> same
>> >> name. I don't think that's allowed by npm.
>> >>
>> >> Your goal was to make configparser its own package right? Doesn't it
>> need
>> >> its own package.json file to be its own package?
>> >>
>> >>
>> >> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer <lo...@gmail.com>
>> wrote:
>> >>
>> >> > Minor bump to cordova-lib to expose a broken out package.
>> >> >
>> >> > history:
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
>> >> >
>> >> > squashed commit to master:
>> >> >
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
>> >> >
>> >> >
>> >> > This does not change any functionality of the modules, just the way
>> >> > they are wired up. It also provides an additional package.json file to
>> >> > better expose the cordova-lib submodules.
>> >> >
>> >> >
>> >> > I think that qualifies as a patch, and should not require a release
>> vote.
>> >> >
>> >> > I will hold off on npm publish for some feedback
>> >> >
>> >> > - Lorin
>> >> >
>> >>
>>
Re: minor bump to cordova-lib
Posted by Michal Mocny <mm...@chromium.org>.
We all wish!
On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer <lo...@gmail.com> wrote:
> Michal: the root package.json is being removed. I do want to perform
> an npm publish with a patch version increment, so downstream projects
> can reference include by npm registry and not git url. That would
> constitute a 'release' of some sort. My understanding was that bug
> patches of this sort could be pushed out with minimum fuss.
>
>
> On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny <mm...@chromium.org> wrote:
> > In particular, I thought the root of the repo wasn't supposed to be a
> node
> > package, but a bucket for multiple node packages. (ie, should not be a
> > package.json at the root).
> >
> > We don't vote on commits (though its nice to ask for review for big hairy
> > patches like this one, so thanks for that).
> >
> > -Michal
> >
> >
> > On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >
> >> I think all releases require votes. Only difference is that for urgent
> >> releases we can have a shorter vote period.
> >>
> >> Looking at your commit - there's now two package.json files with the
> same
> >> name. I don't think that's allowed by npm.
> >>
> >> Your goal was to make configparser its own package right? Doesn't it
> need
> >> its own package.json file to be its own package?
> >>
> >>
> >> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer <lo...@gmail.com>
> wrote:
> >>
> >> > Minor bump to cordova-lib to expose a broken out package.
> >> >
> >> > history:
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
> >> >
> >> > squashed commit to master:
> >> >
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
> >> >
> >> >
> >> > This does not change any functionality of the modules, just the way
> >> > they are wired up. It also provides an additional package.json file to
> >> > better expose the cordova-lib submodules.
> >> >
> >> >
> >> > I think that qualifies as a patch, and should not require a release
> vote.
> >> >
> >> > I will hold off on npm publish for some feedback
> >> >
> >> > - Lorin
> >> >
> >>
>
Re: minor bump to cordova-lib
Posted by Lorin Beer <lo...@gmail.com>.
Michal: the root package.json is being removed. I do want to perform
an npm publish with a patch version increment, so downstream projects
can reference include by npm registry and not git url. That would
constitute a 'release' of some sort. My understanding was that bug
patches of this sort could be pushed out with minimum fuss.
On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny <mm...@chromium.org> wrote:
> In particular, I thought the root of the repo wasn't supposed to be a node
> package, but a bucket for multiple node packages. (ie, should not be a
> package.json at the root).
>
> We don't vote on commits (though its nice to ask for review for big hairy
> patches like this one, so thanks for that).
>
> -Michal
>
>
> On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
>> I think all releases require votes. Only difference is that for urgent
>> releases we can have a shorter vote period.
>>
>> Looking at your commit - there's now two package.json files with the same
>> name. I don't think that's allowed by npm.
>>
>> Your goal was to make configparser its own package right? Doesn't it need
>> its own package.json file to be its own package?
>>
>>
>> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer <lo...@gmail.com> wrote:
>>
>> > Minor bump to cordova-lib to expose a broken out package.
>> >
>> > history:
>> >
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
>> >
>> > squashed commit to master:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
>> >
>> >
>> > This does not change any functionality of the modules, just the way
>> > they are wired up. It also provides an additional package.json file to
>> > better expose the cordova-lib submodules.
>> >
>> >
>> > I think that qualifies as a patch, and should not require a release vote.
>> >
>> > I will hold off on npm publish for some feedback
>> >
>> > - Lorin
>> >
>>
Re: minor bump to cordova-lib
Posted by Michal Mocny <mm...@chromium.org>.
In particular, I thought the root of the repo wasn't supposed to be a node
package, but a bucket for multiple node packages. (ie, should not be a
package.json at the root).
We don't vote on commits (though its nice to ask for review for big hairy
patches like this one, so thanks for that).
-Michal
On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve <ag...@chromium.org> wrote:
> I think all releases require votes. Only difference is that for urgent
> releases we can have a shorter vote period.
>
> Looking at your commit - there's now two package.json files with the same
> name. I don't think that's allowed by npm.
>
> Your goal was to make configparser its own package right? Doesn't it need
> its own package.json file to be its own package?
>
>
> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer <lo...@gmail.com> wrote:
>
> > Minor bump to cordova-lib to expose a broken out package.
> >
> > history:
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
> >
> > squashed commit to master:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
> >
> >
> > This does not change any functionality of the modules, just the way
> > they are wired up. It also provides an additional package.json file to
> > better expose the cordova-lib submodules.
> >
> >
> > I think that qualifies as a patch, and should not require a release vote.
> >
> > I will hold off on npm publish for some feedback
> >
> > - Lorin
> >
>
Re: minor bump to cordova-lib
Posted by Lorin Beer <lo...@gmail.com>.
looking into the duplicate package.json issue
thanks for catching the package.json issue, the duplicate is a
mistaken inclusion
the end goal is that configparser is it's own package, yes. Included
the wrong package.json file
On Mon, Jun 9, 2014 at 12:01 PM, Andrew Grieve <ag...@chromium.org> wrote:
> I think all releases require votes. Only difference is that for urgent
> releases we can have a shorter vote period.
>
> Looking at your commit - there's now two package.json files with the same
> name. I don't think that's allowed by npm.
>
> Your goal was to make configparser its own package right? Doesn't it need
> its own package.json file to be its own package?
>
>
> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer <lo...@gmail.com> wrote:
>
>> Minor bump to cordova-lib to expose a broken out package.
>>
>> history:
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
>>
>> squashed commit to master:
>>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
>>
>>
>> This does not change any functionality of the modules, just the way
>> they are wired up. It also provides an additional package.json file to
>> better expose the cordova-lib submodules.
>>
>>
>> I think that qualifies as a patch, and should not require a release vote.
>>
>> I will hold off on npm publish for some feedback
>>
>> - Lorin
>>
Re: minor bump to cordova-lib
Posted by Andrew Grieve <ag...@chromium.org>.
I think all releases require votes. Only difference is that for urgent
releases we can have a shorter vote period.
Looking at your commit - there's now two package.json files with the same
name. I don't think that's allowed by npm.
Your goal was to make configparser its own package right? Doesn't it need
its own package.json file to be its own package?
On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer <lo...@gmail.com> wrote:
> Minor bump to cordova-lib to expose a broken out package.
>
> history:
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
>
> squashed commit to master:
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
>
>
> This does not change any functionality of the modules, just the way
> they are wired up. It also provides an additional package.json file to
> better expose the cordova-lib submodules.
>
>
> I think that qualifies as a patch, and should not require a release vote.
>
> I will hold off on npm publish for some feedback
>
> - Lorin
>