I think we should get the manual steps ironed out on the
https://wiki.apache.org/cordova/StepsForPluginRelease site before we try to
automate.
I just tried what you said and got:
> ../cordova-plugman/main.js publish .
> forbidden user: agrieve not authorized to modify
> org.apache.cordova.core.fi
Reviving this thread for 3.1
One thing that is not part of [1] is publishing all plugins and
updating versions to our registry.
Could coho automate this process as well ?
Basically we need to run "plugman publish cordova-plugin-*" after
updating each plugin version.
[1] http://wiki.apache.org/c
On Wed, Sep 4, 2013 at 9:17 PM, Andrew Grieve wrote:
>
>
>
> On Wed, Sep 4, 2013 at 5:42 PM, Michal Mocny wrote:
>
>>
>>
>>
>> On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny wrote:
>>
>>>
>>>
>>>
>>> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve wrote:
>>>
On Wed, Sep 4, 2013 at 3:15 PM, And
On Thu, Sep 5, 2013 at 5:45 AM, Plaquette, Paul wrote:
> hi,
>
>
> good idea.
>
> could not it create tags ? (in order to have something more readable than a
> hash)
>
I suppose it could, as long as you didn't push them until they're tested --
my reason for not suggesting that is that you may nee
hi,
good idea.
could not it create tags ? (in order to have something more readable than a
hash)
Cordially
~~~
Paul Plaquette,
Senior Software Engineer
Intel Corporation SAS *
*
*SSG/OTC: Open Source Technology Center*
France, Montpellier
On Thu, Sep 5,
On Wed, Sep 4, 2013 at 9:16 PM, Andrew Grieve wrote:
> Changes should sneak into dev, not master. Unless someone else messed
> something up, there shouldn't be any conflicts on master.
>
> I see what you're saying though. Sneaking a change into dev while you're
> testing would mess you up a bit.
On Wed, Sep 4, 2013 at 5:42 PM, Michal Mocny wrote:
>
>
>
> On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny wrote:
>
>>
>>
>>
>> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve wrote:
>>
>>> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve
>>> wrote:
>>>
>>> >
>>> >
>>> >
>>> > On Wed, Sep 4, 2013 at 2
Changes should sneak into dev, not master. Unless someone else messed
something up, there shouldn't be any conflicts on master.
I see what you're saying though. Sneaking a change into dev while you're
testing would mess you up a bit.
One option is to push after incrementing the version and writin
On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny wrote:
>
>
>
> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve wrote:
>
>> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve
>> wrote:
>>
>> >
>> >
>> >
>> > On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve > >wrote:
>> >
>> >> Responses inline. For all of the
On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve wrote:
> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve
> wrote:
>
> >
> >
> >
> > On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve >wrote:
> >
> >> Responses inline. For all of them, I'll update the wiki to make things
> >> clear.
> >>
> >>
> >> On Tue
On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve wrote:
>
>
>
> On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve wrote:
>
>> Responses inline. For all of them, I'll update the wiki to make things
>> clear.
>>
>>
>> On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny wrote:
>>
>>> For Strategy page:
>>>
>>> R
On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve wrote:
> Responses inline. For all of them, I'll update the wiki to make things
> clear.
>
>
> On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny wrote:
>
>> For Strategy page:
>>
>> RE: Weekly Releases -- do we skip a release if there is nothing
>> signi
Responses inline. For all of them, I'll update the wiki to make things
clear.
On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny wrote:
> For Strategy page:
>
> RE: Weekly Releases -- do we skip a release if there is nothing significant
> to push, or do we release so long as there is at least one pa
For Strategy page:
RE: Weekly Releases -- do we skip a release if there is nothing significant
to push, or do we release so long as there is at least one patch?
RE: Cadence Releases -- "These releases include: platform repos,
cordova-js, mobile-spec, cordova-docs, cordova-cli, cordova-plugman" --
Tools release process looks good to me, but I've not done some parts of
that process before.
Braden
On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny wrote:
> For Strategy page:
>
> RE: Weekly Releases -- do we skip a release if there is nothing significant
> to push, or do we release so long as t
Finally finished updating the wiki's instructions to follow this proposal.
Summary of changes:
https://wiki.apache.org/cordova/VersioningAndReleaseStrategy
- Explains our versioning strategy (SemVer vs CadVer)
https://wiki.apache.org/cordova/CommitterWorkflow
- Extracted Pull Requst Processi
On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve wrote:
> After the discussion on the group hangout + some sleeping, I think we're
> ready for a proposal... So here it is!
> - It does *not* propose any changes to our Deprecation policy. That's for
> another thread (which I'll get to on Monday if no
I'm cool w/ the proposed. (Sounds like plugin versioning still needs
discussion though.)
Also, lets not call the thing we're shipping next year 'Fancy Pants'. (But
lets kick up a thread to talk about that.)
On Fri, Aug 16, 2013 at 5:44 PM, Jesse wrote:
> Too much to discuss in one thread, I am
Too much to discuss in one thread, I am starting a new thread to discuss
plugin versioning.
Cheers,
Jesse
@purplecabbage
risingj.com
On Fri, Aug 16, 2013 at 2:41 PM, Andrew Grieve wrote:
> After the discussion on the group hangout + some sleeping, I think we're
> ready for a proposal... So h
After the discussion on the group hangout + some sleeping, I think we're
ready for a proposal... So here it is!
- It does *not* propose any changes to our Deprecation policy. That's for
another thread (which I'll get to on Monday if no one else does) :)
- It does not contain how we store version nu
On Wed, Aug 7, 2013 at 8:49 PM, Michael Brooks wrote:
> >
> > Plugins and CLI tools I think we should just ship continuously. The
>
Why do you think these should be shipped continuously instead of on a
regular cadence? Note that I think they should be as well, but I'm trying
to figure out why the
The way we release things right now, we don't ensure feature parity across
platforms for releases. The release numbers map strictly to points in time,
so we're already in a world where choosing "3.5" will leave you with
different feature sets across platforms. We could certainly consider
changing t
>
> Plugins and CLI tools I think we should just ship continuously. The
> only question that remains in the 'how' of that is versioning. Mike
> Brookes has advocated semver schema here wherein we version platforms
> separately from the tools using a compound version number. An example
> of this mig
On Wed, Aug 7, 2013 at 12:49 PM, Brian LeRoux wrote:
> I think keeping the cadence on the core platforms makes sense. That is
> where the bulk of logic lives, it is susceptible to 3rd party issues
> like new iDEs and SDKs, and having that regular cadence in lockstep
> makes issue tracking easier
Synchronized versions, releases provides a guidance for what
features/fixes/bugs to be expected at least on the main platforms. Let's
assume that both distro A and distro B are based on Cordova (core) 3.5 but
because they have to choose a platform version on top of the core for each
platform. It w
I think keeping the cadence on the core platforms makes sense. That is
where the bulk of logic lives, it is susceptible to 3rd party issues
like new iDEs and SDKs, and having that regular cadence in lockstep
makes issue tracking easier to discuss with the community.
Plugins and CLI tools I think w
Gorkem, could you elaborate?
On Tue, Aug 6, 2013 at 7:22 PM, Gorkem Ercan wrote:
> Another disadvantage is, this may cause downstream distributions of
> Cordova to get fragmented.
> --
> Gorkem
>
>
>
> On Tue, Aug 6, 2013 at 4:43 PM, Andrew Grieve
> wrote:
>
> > Want to have this as a discuss
Another disadvantage is, this may cause downstream distributions of
Cordova to get fragmented.
--
Gorkem
On Tue, Aug 6, 2013 at 4:43 PM, Andrew Grieve wrote:
> Want to have this as a discussion starter.
>
> We've previously established that:
> 1. Releases for plugman & CLI will not be tied to
Want to have this as a discussion starter.
We've previously established that:
1. Releases for plugman & CLI will not be tied to platform releases
2. Releases to plugins will not be tied to platform releases
That's not to say we shouldn't sometime co-ordinate them with platform
releases, but I thi
29 matches
Mail list logo
