Moving to a 3.6.1 sounds like the only way forward, but let's not publish it until AFTER a vore.
We should be voting on what we see in the git-repos ( after verifying that it is identical to the packaged binaries) We should be testing via --usegit all the npm stuff should just be gravy. Carlos: - The problem is that we won't be voting on what is already published @purplecabbage risingj.com On Thu, Sep 4, 2014 at 12:20 PM, Carlos Santana <csantan...@gmail.com> wrote: > Marcel sounds good approach for consistency and less confusion. but if > something goes wrong with voting again, we will have to do a 3.6.2 > Can we publish to npm as it as 3.6.1-rc1, I think in the past we use to > something similar with with git tags. > If vote passes then we can publish the same content as 3.6.1, and unpublish > 3.6.1-rc from npm > > > > On Thu, Sep 4, 2014 at 3:13 PM, Michal Mocny <mmo...@chromium.org> wrote: > > > That npm issue sounds like a blocker for voting on RC's that have been > > uploaded to npm, since it means we have to update the package after > > successful vote. > > > > Not sure of workarounds. > > > > -Michal > > > > > > On Thu, Sep 4, 2014 at 3:05 PM, Marcel Kinard <cmarc...@gmail.com> > wrote: > > > > > > > > > One idea would be to bump the version of > > > android/amazon-fireos/windows/wp8 to 3.6.1, both in dist.a.o and in > npm. > > > And we could leave all the other platforms/tools at 3.6.0. Except that > we > > > would also need to bump those references in > > > cordova-lib/cordova-lib/src/platforms.js, and then bump the reference > in > > > cordova-cli to use this newer cordova-lib. Not pretty, but it should > work > > > technically. Sigh. > > > > > > If we are going with this approach, I'd actually suggest to bump the > > > version of everything to be 3.6.1, for consistency and less user > > confusion. > > > > > > -- > Carlos Santana > <csantan...@gmail.com> >
