Super true. I am personally very excited for the future wherein we can
iterate the plugins independently (and thusly version).
On Thu, Jun 6, 2013 at 9:54 AM, Braden Shepherdson wrote:
> It's worth remembering that despite the substantial changes of 3.0, most of
> the code backing the APIs has no
It's worth remembering that despite the substantial changes of 3.0, most of
the code backing the APIs has not changed, only moved. Therefore if a bug
exists in 2.x, it will likely exist in 3.0 also. This is especially true of
the bug hotbeds like FileTransfer.
Braden
On Wed, Jun 5, 2013 at 5:06
I like the idea of keeping 2.x around and updating it to fix any bugs filed
for 2.x
As for when to break out the plugins and merge/rebase the 3.0 branch, this
should wait until after 2.9.x is released. Otherwise the users would need
node/plugman in order to create a project, and this is a dependen
There's merits to both and I'm open to either approach. To summarize:
- dump the 3.0 branch into master now, and expand the ./create scripts so
that they call into plugman to re-add the core apis. Pro: gives us more
time to bake the frameworks with plugins ripped out. Con: probably not
ready right
+1.
However, do we want to support 2.x for some extended time during the
tooling transition to 3.x for everyone? One way to do this is just land a
constant stream of point releases on the 2.9.x branch. Another way could
be to branch a 2.x long-lived feature branch before merging in 3.0.0 and
con
+1
Lets do that nao.
On Wed, Jun 5, 2013 at 12:11 PM, Filip Maj wrote:
> Joe and I were just talking about how the process of integrating an
> API-less cordova (I.e. The 3.0 branches) back into the master branches
> would work. I imagine that, as soon as we create a release branch for
> 2.9.0 /
Agreed. When the 3.0 branches were created, I said "they should have been
called 'future' or similar", since that's what they really are. The 3.0
branch that we've been working on so far is not the 3.0.x release branch.
Braden
On Wed, Jun 5, 2013 at 1:41 PM, Ian Clelland wrote:
> That makes se
That makes sense. That is probably the only reason to ever merge such a
branch back into master -- essentially the 3.0.0 branch that we have now is
treated as a 'feature' branch, to be merged into master when it is ready
(and after the long-lived 2.9.x branch splits off).
Then, later, we can actua
Joe and I were just talking about how the process of integrating an
API-less cordova (I.e. The 3.0 branches) back into the master branches
would work. I imagine that, as soon as we create a release branch for
2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into master
right away. Then we
A lot of work is being put into breaking out the plugins into individual
repositories, as a prep for 3.0. One of my goals on this project is to
ship a Cordova for 3.0 that allows users to compose a cordova application
shell with whatever plugins they wish, including the core APIs. This way
users do
10 matches
Mail list logo
