cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: 3.1 Release
Date Wed, 25 Sep 2013 11:31:05 GMT
That's a good summary. I am going to be fixing the reference problem
shortly and merge them back to the `dev` branch. Not sure if all of
Jesse's changes have made it to the `dev` branch yet.

The `edge` docs have already been updated (see CB-4493)

The `3.0` docs will have to be updated once we merge `dev` back to
`master` (which I hope we will before we release 3.1).


On Wed, Sep 25, 2013 at 1:25 AM, Steven Gill <stevengill97@gmail.com> wrote:
> I realize why Anis decided to do a new branch (3.1.0) because he didn't
> want to mess up dev/master. Before we release 3.1.0 we need to do a plugin
> release based off of http://wiki.apache.org/cordova/StepsForPluginRelease.
> Jesse has changes for the plugins that he has pushed to dev now based on
> this email thread. He needs these changes to be in the next plugin release
> we are doing for the 3.1.0 release.
>
> If I am understanding this correctly, removing core from ID was not
> something we want in master due to 3.0.0 support. But this ID change should
> have been done on dev before creating the 3.1.0 branch. The 3.0.0 docs get
> users to install plugins using the git url. The problem is that the 3.0.0
> docs instruct our users to use the ID for plugin removal. Obviously if we
> change the ID, the remove documentation for 3.0.0 would be wrong.
>
> We have two options here as far as I can tell
>
> 1) Leave master alone for the next month or two and give people time to
> migrate to 3.1
> 2) Update the 3.0 documentation to refer to updated id, Push the updated ID
> to dev then master.
>
> Things that need to be done
>  - Fix incorrect references to the old ID (last comment on
> https://issues.apache.org/jira/browse/CB-4889)
>  - Merge these changes into dev (they really should be on dev if that is
> where we all the work done)
>  - Follow steps on http://wiki.apache.org/cordova/StepsForPluginRelease and
> publish these plugins on our registry. This should include Jesse's work as
> well.
>  - Update edge docs to refer to registry for plugin installation (not sure
> if this has been done)
>  - Update 3.0.0 documentation if we decide option 2 from above is the way
> to go
>  - Tag docs 3.1.0-rc1
>
> I volunteer to take the lead on getting the plugins released + tested
> (supposed to be today according to Andrew's timeline) for tomorrow
> afternoon. I can get to the docs after that.
>
> Before I dive into this full steam, any feedback on above?
>
>
>
>
> On Tue, Sep 24, 2013 at 8:08 AM, Michal Mocny <mmocny@chromium.org> wrote:
>
>> Just to be super duper clear: the reason to work on 'dev' branch of plugins
>> is not some process decision we are imposing, its a direct requirement
>> imposed on us by the limitations of our tools (specifically, the state of
>> the registry as it was with 3.0 launch).
>>
>> We discussed this in-depth just a week ago (Read "About plugins in 3.1"),
>> and I think several other times over the last month, if you would like to
>> read up on the details look there.
>>
>> No one likes the situation, we've been making headway into fixing it ever
>> since we discovered the problem, and it can be resolved as soon as users
>> upgrade from 3.0 (maybe that means we can switch after 3.1 release, maybe
>> that means we wait for some 3-months deprecation time, not sure).
>>
>> -Michal
>>
>>
>> On Tue, Sep 24, 2013 at 9:51 AM, Braden Shepherdson <braden@chromium.org
>> >wrote:
>>
>> > I agree with Joe that developing on anything other than master sucks. But
>> > unfortunately, our hands are tied in the near term because the registry
>> > doesn't know to fetch plugins from anywhere else. Also it makes life
>> easier
>> > for being who are installing plugins from git URLs.
>> >
>> > I think we eventually want to get to a world where 99% of plugin installs
>> > are happening from the registry, the registry knows how to fetch tags,
>> and
>> > people who are using git URLs directly know what they're doing and want
>> the
>> > dev version. (Also you can specify branches with #gitref in the URL, so
>> > there's flexibility there.) But we're not there yet.
>> >
>> > Braden
>> >
>> >
>> > On Tue, Sep 24, 2013 at 7:45 AM, Shazron <shazron@gmail.com> wrote:
>> >
>> > > Yes, let's get this cleared up - confused myself.
>> > >
>> > >
>> > > On Tue, Sep 24, 2013 at 3:52 AM, Anis KADRI <anis.kadri@gmail.com>
>> > wrote:
>> > >
>> > > > 3.1.0 is coincidental and it's temporary for this release because
I
>> > > > wasn't sure where to get the code from and didn't want to compromise
>> > > > master or dev. I could have called it something else.
>> > > >
>> > > > Jesse, I'd advise you to commit to dev. Everything will be merged
to
>> > > > master eventually.
>> > > >
>> > > > So to re-iterate the process: right now it's "dev -> master" and
>> > > > eventually it will be "master -> (independant) plugin version".
>> > > > amarite?
>> > > >
>> > > > On Tue, Sep 24, 2013 at 12:08 AM, Joe Bowser <bowserj@gmail.com>
>> > wrote:
>> > > > > On Mon, Sep 23, 2013 at 2:58 PM, Andrew Grieve <
>> agrieve@chromium.org
>> > >
>> > > > wrote:
>> > > > >> Plugins are not tagged nor branched along with platforms.
They are
>> > > > releases
>> > > > >> completely independently.
>> > > > >>
>> > > > >> Commit to the "dev" branch always.
>> > > > >
>> > > > > AND FOREVER!!!!!11!!eleventyone!!!
>> > > > >
>> > > > > Seriously, can't we have a stable branch instead? Having the
dev
>> > > > > branch for dev on plugins and having master for dev on platforms
is
>> > > > > stupid and makes it harder to do work.
>> > > >
>> > >
>> >
>>

Mime
View raw message