cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: 3.1 Release
Date Thu, 26 Sep 2013 06:24:55 GMT
I have merged the dev branches into master on my machine and tagged all of
the plugins. I am planning on merging this into master tomorrow if no one
has any issues.

I will also send a review request for the plugin release blog once I finish
it tomorrow.

Tracking everything at https://issues.apache.org/jira/browse/CB-4915

-Steve


On Wed, Sep 25, 2013 at 10:26 AM, Steven Gill <stevengill97@gmail.com>wrote:

> Michael,
>
> Good point. I think the issue arrises if some of our users keep using 3.0,
> install plugins using the git url (master branch) and then try to remove
> the plugins using the 3.0 documentation. When the master branch gets
> updated, it won't have core in the ID. This will make the remove
> instructions incorrect.
>
> An upgrade guide/blog post actually sounds like the best way to handle
> this issue.
>
> I am going to pick up where Anis left of and aim to do a plugin release
> later this afternoon
>
> -Steve
>
>
> On Wed, Sep 25, 2013 at 6:45 AM, Carlos Santana <csantana23@gmail.com>wrote:
>
>> It could be a doc or or blog post, I would suggest blog post for plugins
>> for more details about dealing with registry since those have a faster
>> pace
>>
>> --Carlos
>>
>>
>>
>> On Wed, Sep 25, 2013 at 9:43 AM, Carlos Santana <csantana23@gmail.com
>> >wrote:
>>
>> > Would suggest we document a simple workflow document "Upgrade Guide
>> > Cordova CLI/PlugMan 3.0 to 3.1"
>> > Same way that we do for the platforms on going over the details in a
>> > single document.
>> >
>> > --Carlos
>> >
>> >
>> > On Wed, Sep 25, 2013 at 9:38 AM, Michal Mocny <mmocny@chromium.org>
>> wrote:
>> >
>> >> I think the 3.0 instructions of removing the old plugin with the old ID
>> >> remain correct even after we update the registry.  Thats because when
>> >> removing plugins from a workspace you use the ID of whats locally
>> >> installed.
>> >>
>> >> So, to upgrade, users would have the use the 3.0 uninstall guide and
>> the
>> >> 3.1 install guide.. I think?
>> >>
>> >> -Michal
>> >>
>> >>
>> >> On Wed, Sep 25, 2013 at 7:31 AM, Anis KADRI <anis.kadri@gmail.com>
>> wrote:
>> >>
>> >> > 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/StepsForPluginReleaseand
>> >> > > 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.
>> >> > >> > > >
>> >> > >> > >
>> >> > >> >
>> >> > >>
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Carlos Santana
>> > <csantana23@gmail.com>
>> >
>>
>>
>>
>> --
>> Carlos Santana
>> <csantana23@gmail.com>
>>
>
>

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