You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2014/04/28 20:30:30 UTC
Some pain points from our users :'(
See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
Re: Some pain points from our users :'(
Posted by Joe Bowser <bo...@gmail.com>.
On Tue, Apr 29, 2014 at 4:55 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Apr 28, 2014, at 2:44 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> I feel the comments there are not really constructive or fair. Cordova
>> changes too much? Sorry, static code means bitrot aka abandonware.
>
> True. But code that is "constantly" changing also means people
> cannot standardize on it and they look for something more
> "stable"... The trick is to find that happy medium.
>
I know you're actively trolling, but I'll still comment on this. Some
facts are important, and unlike you, I actually care about the facts:
1. The code isn't constantly changing. There's still a CLI-less
workflow. You can use plugman to install plugins, or you can copy the
Java classes manually and edit the config.xml so it works like the old
project. This project may be more active than other projects, but my
workflow for actually doing development on PhoneGap and Apache Cordova
hasn't changed in almost four years.
2. The statements made above are absurd. It'd be amazing if Simon and
I magically wrote the best code ever in PhoneGap 1.2 on Android, but I
can tell you right now that version was garbage. That was code
written back in November 2011. All minor versions before 2.x were
done to ramp up to 2.0. We did a much better job ramping up to 3.0,
but democracy and a bit of peer-pressure made sure that we changed a
plugin API namespace at the last minute. That said, find and replace
is trivial to do on all major IDEs and text editors, and isn't worth
the rage that we've seen here.
3. We've kept 2.x support alive for six months before deprecating it.
This was the last version before the pluggable module system.
We have to move at the same pace as mobile, which luckily is slowing
down, but is still ridiculously fast in comparison to server or
desktop development. This means that we have to make sure that we're
future-proof and that our code actually works with the latest SDKs
while we try and add features and make mobile development actually
easier. We've gone to great lengths to provide two methods for
development, and while many people object to us providing both the CLI
(which I recommend to our non-technical users currently) and plugman
(which is easier than just copying over files), I think we're going to
keep doing this for a long time to come, because of our users.
Also, you have to be active when the decision is being made to have
any impact in that decision. The namespace change was a terrible
decision for so many reasons, since it was done to ease contributor
pain at the cost of plugin developers. However, I was the only person
in the discussion thread that pushed back against this, and I pushed
against this as hard as I could. It's extremely hard for us to go
back and reverse decisions once they've been made after a major
release. Saying that your opinion matters a year after the fact is
ridiculous, because not even my opinion mattered a year after the
fact, other than the fact that I was there when it could have, and
have it on the record.
Re: Some pain points from our users :'(
Posted by Josh Soref <js...@blackberry.com>.
Jim Jagielski wrote:
> But code that is "constantly" changing also means people
> cannot standardize on it and they look for something more
> "stable"... The trick is to find that happy medium.
This is nonsense. [Yes, I'm feeding a troll. This may be the last time, I
might have to investigate kill-filing.]
Browsers change constantly. But they've standardized on a back button, a
URL bar, some way to "go", bookmarks, saving, printing.
There is nothing wrong with code changing.
One other thing that the browser developers learned is that getting people
to upgrade in baby steps results in fewer revolts.
We've also seen the reverse in OS's, when MS failed to get people to
migrate from 9x, or from XP, the pain of getting them to upgrade got worse
and worse the longer they delayed. People who upgraded from Win 3.0 -> Win
3.1 -> Win 3.11 had minimal pain. Even 3.11 -> 95 wasn't terrible. People
who upgraded 95 -> 98 -> Me (optional) | 2000 (optional) -> XP -> Vista ->
7 didn't have much pain. Going from 7 -> 8 -> 8.1 isn't bad either.
Sometimes there's more of a change in a given thing, sometimes there's
less. One trick MS used was to try to ensure certain things were
consistent, e.g. If you were used to doing <win>-r, or <win>-e, those
things worked from 95 -> 8.1. <win>,notepad,<enter> worked from Vista->
8.1 (and if you had evolved your start menu in XP or older, something
similar would have worked too).
Migration tools help. MS actually generally puts them together, although I
don't think it does a great job of getting people to use them. Tutorials
and write-ups for workflows/changes also help.
The migration guides that Cordova has had in prior versions were actually
pretty impressive. And I hope that we can put together some automated
tools to help w/ the future.
Re: Some pain points from our users :'(
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 28, 2014, at 2:44 PM, Brian LeRoux <b...@brian.io> wrote:
> I feel the comments there are not really constructive or fair. Cordova
> changes too much? Sorry, static code means bitrot aka abandonware.
True. But code that is "constantly" changing also means people
cannot standardize on it and they look for something more
"stable"... The trick is to find that happy medium.
>
> We work on Cordova because we are improving it for the many thousands of
> our users whom appreciate that. I don't need to tell you guys that but 1.8
> was a mess compared to 3.x and if you are only updating YOUR userland
> source once every 2 years and you don't expect it to be come with
> problems?! The bugs found usually are not introduced by us but with Xcode,
> iOS, or Android and we are FIXING those things with updates.
>
> Docs are a problem but as they say patches welcome. This is the sort of
> entitled complaint that lead me off that list.
>
>
>
> On Mon, Apr 28, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
>
>> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
>>
Re: Some pain points from our users :'(
Posted by Joe Bowser <bo...@gmail.com>.
On Mon, Apr 28, 2014 at 11:44 AM, Brian LeRoux <b...@brian.io> wrote:
> I feel the comments there are not really constructive or fair. Cordova
> changes too much? Sorry, static code means bitrot aka abandonware.
>
> We work on Cordova because we are improving it for the many thousands of
> our users whom appreciate that. I don't need to tell you guys that but 1.8
> was a mess compared to 3.x and if you are only updating YOUR userland
> source once every 2 years and you don't expect it to be come with
> problems?! The bugs found usually are not introduced by us but with Xcode,
> iOS, or Android and we are FIXING those things with updates.
>
Dude, this is the #1 complaint I get from everyone who uses our stuff.
Our users don't have massive dev teams to deal with the changes that
we do. Often, the same dev who is working on the PhoneGap app is also
doing the backend work, most likely maintaining some broken-ass Rails
2 system, and probably works stupid long days for mediocre pay, or
equity in a startup which may never ship anything. We can't solve
those problems, because most of those are probably poor life choices,
but we should be able to tell people how to migrate from old and
broken to new and mostly working and point out some pain points.
That said, I think that having an LTS is absolutely stupid given that
six years ago, Mobile wasn't really a thing, and two years ago,
Jellybean just started to exist. Perhaps when mobile starts to slow
down a bit more, this might make sense, but I highly doubt it.
> Docs are a problem but as they say patches welcome. This is the sort of
> entitled complaint that lead me off that list.
>
These still are our users, and they're probably the majority of our
users, whether we like them or not. I don't like these people, but
their complaints aren't totally without merit.
>
>
> On Mon, Apr 28, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
>
>> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
>>
Re: Some pain points from our users :'(
Posted by Brian LeRoux <b...@brian.io>.
We need to clone Tommy for the various channels and convince Mike Sierra to
come back and continue docs. Good problems to have at least.
On Mon, Apr 28, 2014 at 11:54 AM, Shazron <sh...@gmail.com> wrote:
> We come with a (framework) developer's perspective, thus an echo chamber.
> The comments may or may not be fair but the users do encounter pain, and I
> think it does help in identifying issues we missed (reading from the list
> overall). Canary in the coal mine, etc.
>
> Filing issues etc ideal, but some, for whatever reason, do not like that
> type of forum, but still choose the Google Groups.
>
>
>
>
> On Mon, Apr 28, 2014 at 11:44 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > I feel the comments there are not really constructive or fair. Cordova
> > changes too much? Sorry, static code means bitrot aka abandonware.
> >
> > We work on Cordova because we are improving it for the many thousands of
> > our users whom appreciate that. I don't need to tell you guys that but
> 1.8
> > was a mess compared to 3.x and if you are only updating YOUR userland
> > source once every 2 years and you don't expect it to be come with
> > problems?! The bugs found usually are not introduced by us but with
> Xcode,
> > iOS, or Android and we are FIXING those things with updates.
> >
> > Docs are a problem but as they say patches welcome. This is the sort of
> > entitled complaint that lead me off that list.
> >
> >
> >
> > On Mon, Apr 28, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
> >
> > > See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
> > >
> >
>
Re: Some pain points from our users :'(
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
For what it's worth, the biggest problem I've had in upgrading is with
'phonegap plugin add <plugin>'. The native code gets copied but
cordova_plugins.js doesn't get updated and the plugin JS isn't wrapped
in a call to cordova.define. In a couple of Stack Overflow posts,
running 'phonegap build <platform>' after adding a plugin is suggested
but I don't see that documented in the Phonegap docs. Plus, that
overwrites the www directory so it has to be copied beforehand which is
troublesome if there are platform-specific customizations. (Is that the
only time the outer www is used?) In addition, I didn't find
documentation for the contents of cordova_plugins.js or the linkage
between it and the plugin JS so I wasn't sure what was required and had
to piece that together on my own. In the end, I manually updated
cordova_plugin.js and the plugin JS files which is way more hairs than I
think was intended.
Overall, I still think Cordova is great framework but that improved
documentation would go a long way towards making that more apparent.
-Terence
On 4/28/2014 2:15 PM, Michal Mocny wrote:
> s/mailing list/distribution list/
>
>
> On Mon, Apr 28, 2014 at 3:14 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>> I think this particular users' frustration is not addressable (and his
>> feedback in places is just annoying: "you work for X and I demand that you
>> should have the money to do everything for me").
>> He hasn't maintained his project for 2 years, hasn't read our docs, hasn't
>> written tests to guard against platform assumptions, and expects to update
>> everything in a few hours.
>> There are a few issues he got hit with (plugin authoring with the CLI is a
>> pain in the butt, 3.4 release plugin docs issue), but generally its
>> probably not worth putting to much weight into it.
>>
>> More broadly, though, perhaps we should acknowledge that we will never
>> catch all issues with releases and try to find ways to incentivize the
>> community to help test out RC's for us? Perhaps a dedicated mailing list
>> for known developers who stay bleeding edge that we email as part of
>> starting the release vote process / at the end of [DISCUSS] thread?
>>
>> -Michal
>>
>>
>> On Mon, Apr 28, 2014 at 2:54 PM, Shazron <sh...@gmail.com> wrote:
>>
>>> We come with a (framework) developer's perspective, thus an echo chamber.
>>> The comments may or may not be fair but the users do encounter pain, and I
>>> think it does help in identifying issues we missed (reading from the list
>>> overall). Canary in the coal mine, etc.
>>>
>>> Filing issues etc ideal, but some, for whatever reason, do not like that
>>> type of forum, but still choose the Google Groups.
>>>
>>>
>>>
>>>
>>> On Mon, Apr 28, 2014 at 11:44 AM, Brian LeRoux <b...@brian.io> wrote:
>>>
>>>> I feel the comments there are not really constructive or fair. Cordova
>>>> changes too much? Sorry, static code means bitrot aka abandonware.
>>>>
>>>> We work on Cordova because we are improving it for the many thousands of
>>>> our users whom appreciate that. I don't need to tell you guys that but
>>> 1.8
>>>> was a mess compared to 3.x and if you are only updating YOUR userland
>>>> source once every 2 years and you don't expect it to be come with
>>>> problems?! The bugs found usually are not introduced by us but with
>>> Xcode,
>>>> iOS, or Android and we are FIXING those things with updates.
>>>>
>>>> Docs are a problem but as they say patches welcome. This is the sort of
>>>> entitled complaint that lead me off that list.
>>>>
>>>>
>>>>
>>>> On Mon, Apr 28, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
>>>>
>>>>> See:
>>> https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
>>
Re: Some pain points from our users :'(
Posted by Michal Mocny <mm...@chromium.org>.
s/mailing list/distribution list/
On Mon, Apr 28, 2014 at 3:14 PM, Michal Mocny <mm...@chromium.org> wrote:
> I think this particular users' frustration is not addressable (and his
> feedback in places is just annoying: "you work for X and I demand that you
> should have the money to do everything for me").
> He hasn't maintained his project for 2 years, hasn't read our docs, hasn't
> written tests to guard against platform assumptions, and expects to update
> everything in a few hours.
> There are a few issues he got hit with (plugin authoring with the CLI is a
> pain in the butt, 3.4 release plugin docs issue), but generally its
> probably not worth putting to much weight into it.
>
> More broadly, though, perhaps we should acknowledge that we will never
> catch all issues with releases and try to find ways to incentivize the
> community to help test out RC's for us? Perhaps a dedicated mailing list
> for known developers who stay bleeding edge that we email as part of
> starting the release vote process / at the end of [DISCUSS] thread?
>
> -Michal
>
>
> On Mon, Apr 28, 2014 at 2:54 PM, Shazron <sh...@gmail.com> wrote:
>
>> We come with a (framework) developer's perspective, thus an echo chamber.
>> The comments may or may not be fair but the users do encounter pain, and I
>> think it does help in identifying issues we missed (reading from the list
>> overall). Canary in the coal mine, etc.
>>
>> Filing issues etc ideal, but some, for whatever reason, do not like that
>> type of forum, but still choose the Google Groups.
>>
>>
>>
>>
>> On Mon, Apr 28, 2014 at 11:44 AM, Brian LeRoux <b...@brian.io> wrote:
>>
>> > I feel the comments there are not really constructive or fair. Cordova
>> > changes too much? Sorry, static code means bitrot aka abandonware.
>> >
>> > We work on Cordova because we are improving it for the many thousands of
>> > our users whom appreciate that. I don't need to tell you guys that but
>> 1.8
>> > was a mess compared to 3.x and if you are only updating YOUR userland
>> > source once every 2 years and you don't expect it to be come with
>> > problems?! The bugs found usually are not introduced by us but with
>> Xcode,
>> > iOS, or Android and we are FIXING those things with updates.
>> >
>> > Docs are a problem but as they say patches welcome. This is the sort of
>> > entitled complaint that lead me off that list.
>> >
>> >
>> >
>> > On Mon, Apr 28, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
>> >
>> > > See:
>> https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
>> > >
>> >
>>
>
>
Re: Some pain points from our users :'(
Posted by Michal Mocny <mm...@chromium.org>.
I think this particular users' frustration is not addressable (and his
feedback in places is just annoying: "you work for X and I demand that you
should have the money to do everything for me").
He hasn't maintained his project for 2 years, hasn't read our docs, hasn't
written tests to guard against platform assumptions, and expects to update
everything in a few hours.
There are a few issues he got hit with (plugin authoring with the CLI is a
pain in the butt, 3.4 release plugin docs issue), but generally its
probably not worth putting to much weight into it.
More broadly, though, perhaps we should acknowledge that we will never
catch all issues with releases and try to find ways to incentivize the
community to help test out RC's for us? Perhaps a dedicated mailing list
for known developers who stay bleeding edge that we email as part of
starting the release vote process / at the end of [DISCUSS] thread?
-Michal
On Mon, Apr 28, 2014 at 2:54 PM, Shazron <sh...@gmail.com> wrote:
> We come with a (framework) developer's perspective, thus an echo chamber.
> The comments may or may not be fair but the users do encounter pain, and I
> think it does help in identifying issues we missed (reading from the list
> overall). Canary in the coal mine, etc.
>
> Filing issues etc ideal, but some, for whatever reason, do not like that
> type of forum, but still choose the Google Groups.
>
>
>
>
> On Mon, Apr 28, 2014 at 11:44 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > I feel the comments there are not really constructive or fair. Cordova
> > changes too much? Sorry, static code means bitrot aka abandonware.
> >
> > We work on Cordova because we are improving it for the many thousands of
> > our users whom appreciate that. I don't need to tell you guys that but
> 1.8
> > was a mess compared to 3.x and if you are only updating YOUR userland
> > source once every 2 years and you don't expect it to be come with
> > problems?! The bugs found usually are not introduced by us but with
> Xcode,
> > iOS, or Android and we are FIXING those things with updates.
> >
> > Docs are a problem but as they say patches welcome. This is the sort of
> > entitled complaint that lead me off that list.
> >
> >
> >
> > On Mon, Apr 28, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
> >
> > > See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
> > >
> >
>
Re: Some pain points from our users :'(
Posted by Shazron <sh...@gmail.com>.
We come with a (framework) developer's perspective, thus an echo chamber.
The comments may or may not be fair but the users do encounter pain, and I
think it does help in identifying issues we missed (reading from the list
overall). Canary in the coal mine, etc.
Filing issues etc ideal, but some, for whatever reason, do not like that
type of forum, but still choose the Google Groups.
On Mon, Apr 28, 2014 at 11:44 AM, Brian LeRoux <b...@brian.io> wrote:
> I feel the comments there are not really constructive or fair. Cordova
> changes too much? Sorry, static code means bitrot aka abandonware.
>
> We work on Cordova because we are improving it for the many thousands of
> our users whom appreciate that. I don't need to tell you guys that but 1.8
> was a mess compared to 3.x and if you are only updating YOUR userland
> source once every 2 years and you don't expect it to be come with
> problems?! The bugs found usually are not introduced by us but with Xcode,
> iOS, or Android and we are FIXING those things with updates.
>
> Docs are a problem but as they say patches welcome. This is the sort of
> entitled complaint that lead me off that list.
>
>
>
> On Mon, Apr 28, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
>
> > See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
> >
>
Re: Some pain points from our users :'(
Posted by Joe Bowser <bo...@gmail.com>.
Oh yeah, this too:
https://github.com/infil00p/cordova-android/commit/9911202d5b2a5f07ba2050176f72c3642a34a8c6
On Mon, Apr 28, 2014 at 2:49 PM, Joe Bowser <bo...@gmail.com> wrote:
> On Mon, Apr 28, 2014 at 2:32 PM, Freak Show <fr...@me.com> wrote:
>>
>>
>> I guess maybe you're new.
>
> https://github.com/phonegap/phonegap/commit/1beb1b5f6ac7470eb516768ef52ceda8df6278e1
Re: Some pain points from our users :'(
Posted by Joe Bowser <bo...@gmail.com>.
On Mon, Apr 28, 2014 at 2:32 PM, Freak Show <fr...@me.com> wrote:
>
>
> I guess maybe you're new.
https://github.com/phonegap/phonegap/commit/1beb1b5f6ac7470eb516768ef52ceda8df6278e1
Re: Some pain points from our users :'(
Posted by Freak Show <fr...@me.com>.
On Apr 28, 2014, at 1:54 PM, Joe Bowser <bo...@gmail.com> wrote:
> On Mon, Apr 28, 2014 at 1:49 PM, Freak Show <fr...@me.com> wrote:
>>
>> On Apr 28, 2014, at 1:36 PM, Joe Bowser <bo...@gmail.com> wrote:
>>
>>> This wasn't necessary and I was against it.
>>
>> Cool - now there are two of us.
>
> Strange, I don't remember hearing from you before today? Which commits
> are you responsible for?
I guess maybe you're new.
https://groups.google.com/forum/#!topic/phonegap/1SqYdrR_3aE
Look for "Blanchard"
There's more work lying around on camera, file, etc. Just not lately. Like not since the acquisition by Adobe because I eventually got the idea things were too much in flux and that Nitobi wasn't really taking the project very seriously so I moved on for a bit.
I do have three shipping products based on it though so I joined the mailing list to try to keep current.
I've been here for over six months haven't said anything until today.
I'm pretty much done commenting unless you have specific questions. I've said what I wanted to say.
-Todd Blanchard
Re: Some pain points from our users :'(
Posted by Joe Bowser <bo...@gmail.com>.
On Mon, Apr 28, 2014 at 1:49 PM, Freak Show <fr...@me.com> wrote:
>
> On Apr 28, 2014, at 1:36 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> This wasn't necessary and I was against it.
>
> Cool - now there are two of us.
Strange, I don't remember hearing from you before today? Which commits
are you responsible for?
Re: Some pain points from our users :'(
Posted by Brian LeRoux <b...@brian.io>.
Cordova has a CLI. The fact that PhoneGap has one and is different is
irrelevant to this list. This is the Cordova mailing list. Why is it
different? We donated the PhoneGap source to Apache and it needs to be
different for a variety of reasons I'd be happy to share on a personal
thread or over a beer.
Plugman is consumed by the Cordova CLI. The CLI is for working with Cordova
projects whereas Plugman is utilized for working with native platforms.
(Just iOS for example.) Sometimes this is called 'separation of concerns'.
Comments like "just building apps out here, its not rocket science" are
harmful. I'm happy to help if you have a real issue but please consider
there are a large number of people working very hard as volunteers and they
don't need abuse.
We do need help though. Your emails indicate you might want to.
I'd recommend starting by reading up on wiki [1].
Even a failing test or reporting a bug for the issues (real issues) that
you helps.
Thanks!
[1] http://wiki.apache.org/cordova/ContributorWorkflow
On Mon, Apr 28, 2014 at 1:49 PM, Freak Show <fr...@me.com> wrote:
>
> On Apr 28, 2014, at 1:36 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > This wasn't necessary and I was against it.
>
> Cool - now there are two of us.
>
> > These reasons were legal, and it was done to keep PhoneGap open
> > source. If we didn't do this, we wouldn't be having this
> > conversation.
>
>
> And this explains where there is a phonegap cli tool and a cordova cli
> tool and they work differently? Nevermind plugman which I totally can't
> figure out.
>
> I don't even want cli tools. I don't care about them I was perfectly
> happy doing git clones into a directory. I just want a well documented
> directory structure and I'll put my stuff together thanks.
>
> None of my experiments with your cli tools and my own plugins have panned
> out. In the end I end up with
> a very custom XCode and/or Eclipse project that somehow I've made work via
> various bits of lucky hackery. We're just building apps out here, its not
> rocket science and if your users had a lot of free time on their hands,
> they'd build native apps instead. Consider that.
>
> I think when you get to the point that you're writing software that writes
> software you really need to take a step back and think about what you're
> doing.
>
>
>
Re: Some pain points from our users :'(
Posted by Freak Show <fr...@me.com>.
On Apr 28, 2014, at 1:36 PM, Joe Bowser <bo...@gmail.com> wrote:
> This wasn't necessary and I was against it.
Cool - now there are two of us.
> These reasons were legal, and it was done to keep PhoneGap open
> source. If we didn't do this, we wouldn't be having this
> conversation.
And this explains where there is a phonegap cli tool and a cordova cli tool and they work differently? Nevermind plugman which I totally can't figure out.
I don't even want cli tools. I don't care about them I was perfectly happy doing git clones into a directory. I just want a well documented directory structure and I'll put my stuff together thanks.
None of my experiments with your cli tools and my own plugins have panned out. In the end I end up with
a very custom XCode and/or Eclipse project that somehow I've made work via various bits of lucky hackery. We're just building apps out here, its not rocket science and if your users had a lot of free time on their hands, they'd build native apps instead. Consider that.
I think when you get to the point that you're writing software that writes software you really need to take a step back and think about what you're doing.
Re: Some pain points from our users :'(
Posted by Joe Bowser <bo...@gmail.com>.
On Mon, Apr 28, 2014 at 1:01 PM, Freak Show <fr...@me.com> wrote:
>
> Because 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, etc....all came with some fatal problem relative to 1.2. Some plugin or other was broken. None of those versions offered new capabilities - but often came with new bugs. That's my perspective on it. Furthermore, I wrote custom plugins on that api. They still work. They are very fancy plugins. I don't care too much that you made "architectural improvements" - from my perspective you just moved the furniture around - nothing pre 2.0 was actually better in any way. Then there's the gratuitous name change confusions that went on. Phonegap vs Cordova changed a bunch of internal names for no really good reason.
These reasons were legal, and it was done to keep PhoneGap open
source. If we didn't do this, we wouldn't be having this
conversation.
>
> Even Apple was smart enough not to change all their api prefixes from NS when they bought NextStep. Gratuitous code breakage seemed to be the rule of the day for awhile.
You are aware that this is an Open Source project, right?
>
> K, that's ancient history but if you're feeling butt hurt about excessive changes, I would like to point out that things looked very keystone cops from the consumer's point of view prior to 2.0. Furthermore all this shifting kept breaking third party plugins.
We didn't have a proper API for plugins prior to 2.0. In fact, I
would argue that our Java APIs are still not fully up to par. That
being said, 2.0 brought the CordovaWebView feature, which allowed
Android developers to embed the view, and set the framework for our
third-party webview work that we're doing now to work around problems
with the Android WebView. There are also the improvements to the
Javascript bridge as well. If you don't feel that those were
improvements, there's not much more we can say about that.
> I get stuff has to progress but this:
>
> you will need to change the path to the following two classes within the Java plugin code for android:
>
> 1
> 2
> import org.apache.cordova.api.CallbackContext;
> import org.apache.cordova.api.CordovaPlugin;
> -to-
>
> 1
> 2
> import org.apache.cordova.CallbackContext;
> import org.apache.cordova.CordovaPlugin;
>
> This was necessary exactly - why? Its "nicer" I guess but you could have lived with the extra level of indirection and not forced those of us who are very busy to have to run around doing string replacement in our custom plugins.
This wasn't necessary and I was against it. However, since I was the
only developer against it, we ended up adopting it. I already said "I
told you so" a year ago, you saying it again is just as helpful.
I would like to remind everyone of my favourite line the Apache
Software Licence:
7. Disclaimer of Warranty. Unless required by applicable law or agreed
to in writing, Licensor provides the Work (and each Contributor
provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR
CONDITIONS OF ANY KIND, either express or implied, including, without
limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT,
MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely
responsible for determining the appropriateness of using or
redistributing the Work and assume any risks associated with Your
exercise of permissions under this License.
as well as this line in the MIT licence:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I think I'm just going to leave these here.
Re: Some pain points from our users :'(
Posted by Freak Show <fr...@me.com>.
I think they are fair, or at least were.
I have an app running on 1.2. Its staying there. Why?
Because 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, etc....all came with some fatal problem relative to 1.2. Some plugin or other was broken. None of those versions offered new capabilities - but often came with new bugs. That's my perspective on it. Furthermore, I wrote custom plugins on that api. They still work. They are very fancy plugins. I don't care too much that you made "architectural improvements" - from my perspective you just moved the furniture around - nothing pre 2.0 was actually better in any way. Then there's the gratuitous name change confusions that went on. Phonegap vs Cordova changed a bunch of internal names for no really good reason.
Even Apple was smart enough not to change all their api prefixes from NS when they bought NextStep. Gratuitous code breakage seemed to be the rule of the day for awhile.
K, that's ancient history but if you're feeling butt hurt about excessive changes, I would like to point out that things looked very keystone cops from the consumer's point of view prior to 2.0. Furthermore all this shifting kept breaking third party plugins.
For instance 1.4-1.5
http://simonmacdonald.blogspot.com/2012/04/migrating-your-phonegap-plugins-to.html
And again when we hit 2.0
http://simonmacdonald.blogspot.com/2012/07/updates-to-plugins-for-phonegap-200.html
And one more time for 3.0
http://devgirl.org/2013/09/05/phonegap-3-0-stuff-you-should-know/
I get stuff has to progress but this:
you will need to change the path to the following two classes within the Java plugin code for android:
1
2
import org.apache.cordova.api.CallbackContext;
import org.apache.cordova.api.CordovaPlugin;
-to-
1
2
import org.apache.cordova.CallbackContext;
import org.apache.cordova.CordovaPlugin;
This was necessary exactly - why? Its "nicer" I guess but you could have lived with the extra level of indirection and not forced those of us who are very busy to have to run around doing string replacement in our custom plugins.
I'm also not too fond of the introduction of not one but *two* sets of command line tools that are supposed to make managing plugins easy. They do the opposite. They generally terminate with incomprehensible errors and the barrier to writing my own plugins has gone stratospheric compared to what I had to do in 1.2.
Furthermore...3.0 doesn't do much of anything from the developer's point of view that 1.2 didn't. So what is with all the changes? I'm not seeing the value. The same plugins ship, they do the same things, but you keep making this backwards incompatible and more and more complicated.
Rant over. But I felt like it needed saying.
-Todd Blanchard
On Apr 28, 2014, at 11:44 AM, Brian LeRoux <b...@brian.io> wrote:
> I feel the comments there are not really constructive or fair. Cordova
> changes too much? Sorry, static code means bitrot aka abandonware.
>
> We work on Cordova because we are improving it for the many thousands of
> our users whom appreciate that. I don't need to tell you guys that but 1.8
> was a mess compared to 3.x and if you are only updating YOUR userland
> source once every 2 years and you don't expect it to be come with
> problems?! The bugs found usually are not introduced by us but with Xcode,
> iOS, or Android and we are FIXING those things with updates.
>
> Docs are a problem but as they say patches welcome. This is the sort of
> entitled complaint that lead me off that list.
>
>
>
> On Mon, Apr 28, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
>
>> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
>>
Re: Some pain points from our users :'(
Posted by Brian LeRoux <b...@brian.io>.
I feel the comments there are not really constructive or fair. Cordova
changes too much? Sorry, static code means bitrot aka abandonware.
We work on Cordova because we are improving it for the many thousands of
our users whom appreciate that. I don't need to tell you guys that but 1.8
was a mess compared to 3.x and if you are only updating YOUR userland
source once every 2 years and you don't expect it to be come with
problems?! The bugs found usually are not introduced by us but with Xcode,
iOS, or Android and we are FIXING those things with updates.
Docs are a problem but as they say patches welcome. This is the sort of
entitled complaint that lead me off that list.
On Mon, Apr 28, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
>
Re: Some pain points from our users :'(
Posted by Joe Bowser <bo...@gmail.com>.
Can we keep track of which users make up which conspiracy theory, and
the company that gets mentioned as ruining Cordova the most has to buy
beer? I say this because at least this time Google got mentioned with
Adobe, as opposed to "Adobe is going to kill
PhoneGap!!!!1!!!eleventyone!!!" (Seriously, if Adobe was, we wouldn't
be here).
Seriously though, the upgrade path between 2.1 and 3.x is so painful,
you have to tell people to throw everything out but their HTML/JS/CSS
and start over. Make sure when they throw everything out that they
throw out phonegap.js/cordova.js as well.
On Mon, Apr 28, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
RE: Some pain points from our users :'(
Posted by Ray Camden <ra...@adobe.com>.
It took some time to actually register, but I'll give it a shot. Traveling today but will try to get a basic outline up there asap. (And anyone else listening - don't wait for me - attack the doc if you can. :)
________________________________________
From: Marcel Kinard <cm...@gmail.com>
Sent: Wednesday, April 30, 2014 10:41 AM
To: dev@cordova.apache.org
Subject: Re: Some pain points from our users :'(
How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this works, as long as the contributions are considered "trivial" by Apache standards. Otherwise pull requests to cordova-doc.git would be the [slower and more proper] way to go.
On Apr 30, 2014, at 11:29 AM, Ray Camden <ra...@adobe.com> wrote:
> Any particular place? Sorry if obvious - but it would need to be a github repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
Re: Some pain points from our users :'(
Posted by Carlos Santana <cs...@gmail.com>.
Sorry for being late to the party.
When I was a consumer of Phonegap back in the days, my most precious doc
was the upgrade guides [1]. We didn't have the bandwidth or test process to
update our app with every release of phonegap. But when it was time to
upgrade (i.e. 1.4 to 1.9) The upgrade guide was my only resource to go over
every change release by release, and I was happy after a week getting my
app updated.
I think having the same for the Plugins will be of benefit to the consumers.
In order of priorities:
*1. Having a upgrade guide per plugin including api changes*
2. If we can, try to adopt semver and change the version according to the
level of change
As we document the breaking changes, we will feel the pain of consumers,
and as we write a lot of doc for upgrading we will want not to doc and
leave the api stable.
[1]:
http://cordova.apache.org/docs/en/3.4.0/guide_platforms_android_upgrading.md.html#Upgrading%20Android
http://cordova.apache.org/docs/en/3.4.0/guide_platforms_ios_upgrading.md.html#Upgrading%20iOS
On Wed, Apr 30, 2014 at 9:36 AM, Michal Mocny <mm...@chromium.org> wrote:
> Thanks for choosing a saner option than the wiki ;)
>
>
> On Wed, Apr 30, 2014 at 12:34 PM, Ray Camden <ra...@adobe.com> wrote:
>
> > Ok folks, here is the document. I even took a quick stab at an outline.
> > I've set this as Anyone Can Edit, but if that causes problems I'll set it
> > back to invited folks only.
> >
> >
> >
> https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit?usp=sharing
> >
> >
> > ________________________________________
> > From: Ray Camden <ra...@adobe.com>
> > Sent: Wednesday, April 30, 2014 11:28 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Some pain points from our users :'(
> >
> > On it.
> > ________________________________________
> > From: Steven Gill <st...@gmail.com>
> > Sent: Wednesday, April 30, 2014 11:12 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Some pain points from our users :'(
> >
> > I would suggest creating a Google doc and sharing it here.
> > On Apr 30, 2014 8:59 AM, "Ray Camden" <ra...@adobe.com> wrote:
> >
> > > Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it.
> > >
> > > ________________________________________
> > > From: Marcel Kinard <cm...@gmail.com>
> > > Sent: Wednesday, April 30, 2014 10:41 AM
> > > To: dev@cordova.apache.org
> > > Subject: Re: Some pain points from our users :'(
> > >
> > > How about here? https://wiki.apache.org/cordova/signposts-draft . I'd
> > > hope this works, as long as the contributions are considered "trivial"
> by
> > > Apache standards. Otherwise pull requests to cordova-doc.git would be
> the
> > > [slower and more proper] way to go.
> > >
> > > On Apr 30, 2014, at 11:29 AM, Ray Camden <ra...@adobe.com> wrote:
> > >
> > > > Any particular place? Sorry if obvious - but it would need to be a
> > > github repo multiple folks can edit. (Seems like that would be quicker
> > than
> > > PRs imo.)
> > >
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: Some pain points from our users :'(
Posted by Michal Mocny <mm...@chromium.org>.
Thanks for choosing a saner option than the wiki ;)
On Wed, Apr 30, 2014 at 12:34 PM, Ray Camden <ra...@adobe.com> wrote:
> Ok folks, here is the document. I even took a quick stab at an outline.
> I've set this as Anyone Can Edit, but if that causes problems I'll set it
> back to invited folks only.
>
>
> https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit?usp=sharing
>
>
> ________________________________________
> From: Ray Camden <ra...@adobe.com>
> Sent: Wednesday, April 30, 2014 11:28 AM
> To: dev@cordova.apache.org
> Subject: RE: Some pain points from our users :'(
>
> On it.
> ________________________________________
> From: Steven Gill <st...@gmail.com>
> Sent: Wednesday, April 30, 2014 11:12 AM
> To: dev@cordova.apache.org
> Subject: RE: Some pain points from our users :'(
>
> I would suggest creating a Google doc and sharing it here.
> On Apr 30, 2014 8:59 AM, "Ray Camden" <ra...@adobe.com> wrote:
>
> > Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it.
> >
> > ________________________________________
> > From: Marcel Kinard <cm...@gmail.com>
> > Sent: Wednesday, April 30, 2014 10:41 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Some pain points from our users :'(
> >
> > How about here? https://wiki.apache.org/cordova/signposts-draft . I'd
> > hope this works, as long as the contributions are considered "trivial" by
> > Apache standards. Otherwise pull requests to cordova-doc.git would be the
> > [slower and more proper] way to go.
> >
> > On Apr 30, 2014, at 11:29 AM, Ray Camden <ra...@adobe.com> wrote:
> >
> > > Any particular place? Sorry if obvious - but it would need to be a
> > github repo multiple folks can edit. (Seems like that would be quicker
> than
> > PRs imo.)
> >
>
RE: Some pain points from our users :'(
Posted by Ray Camden <ra...@adobe.com>.
Ok folks, here is the document. I even took a quick stab at an outline. I've set this as Anyone Can Edit, but if that causes problems I'll set it back to invited folks only.
https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit?usp=sharing
________________________________________
From: Ray Camden <ra...@adobe.com>
Sent: Wednesday, April 30, 2014 11:28 AM
To: dev@cordova.apache.org
Subject: RE: Some pain points from our users :'(
On it.
________________________________________
From: Steven Gill <st...@gmail.com>
Sent: Wednesday, April 30, 2014 11:12 AM
To: dev@cordova.apache.org
Subject: RE: Some pain points from our users :'(
I would suggest creating a Google doc and sharing it here.
On Apr 30, 2014 8:59 AM, "Ray Camden" <ra...@adobe.com> wrote:
> Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it.
>
> ________________________________________
> From: Marcel Kinard <cm...@gmail.com>
> Sent: Wednesday, April 30, 2014 10:41 AM
> To: dev@cordova.apache.org
> Subject: Re: Some pain points from our users :'(
>
> How about here? https://wiki.apache.org/cordova/signposts-draft . I'd
> hope this works, as long as the contributions are considered "trivial" by
> Apache standards. Otherwise pull requests to cordova-doc.git would be the
> [slower and more proper] way to go.
>
> On Apr 30, 2014, at 11:29 AM, Ray Camden <ra...@adobe.com> wrote:
>
> > Any particular place? Sorry if obvious - but it would need to be a
> github repo multiple folks can edit. (Seems like that would be quicker than
> PRs imo.)
>
RE: Some pain points from our users :'(
Posted by Ray Camden <ra...@adobe.com>.
On it.
________________________________________
From: Steven Gill <st...@gmail.com>
Sent: Wednesday, April 30, 2014 11:12 AM
To: dev@cordova.apache.org
Subject: RE: Some pain points from our users :'(
I would suggest creating a Google doc and sharing it here.
On Apr 30, 2014 8:59 AM, "Ray Camden" <ra...@adobe.com> wrote:
> Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it.
>
> ________________________________________
> From: Marcel Kinard <cm...@gmail.com>
> Sent: Wednesday, April 30, 2014 10:41 AM
> To: dev@cordova.apache.org
> Subject: Re: Some pain points from our users :'(
>
> How about here? https://wiki.apache.org/cordova/signposts-draft . I'd
> hope this works, as long as the contributions are considered "trivial" by
> Apache standards. Otherwise pull requests to cordova-doc.git would be the
> [slower and more proper] way to go.
>
> On Apr 30, 2014, at 11:29 AM, Ray Camden <ra...@adobe.com> wrote:
>
> > Any particular place? Sorry if obvious - but it would need to be a
> github repo multiple folks can edit. (Seems like that would be quicker than
> PRs imo.)
>
RE: Some pain points from our users :'(
Posted by Steven Gill <st...@gmail.com>.
I would suggest creating a Google doc and sharing it here.
On Apr 30, 2014 8:59 AM, "Ray Camden" <ra...@adobe.com> wrote:
> Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it.
>
> ________________________________________
> From: Marcel Kinard <cm...@gmail.com>
> Sent: Wednesday, April 30, 2014 10:41 AM
> To: dev@cordova.apache.org
> Subject: Re: Some pain points from our users :'(
>
> How about here? https://wiki.apache.org/cordova/signposts-draft . I'd
> hope this works, as long as the contributions are considered "trivial" by
> Apache standards. Otherwise pull requests to cordova-doc.git would be the
> [slower and more proper] way to go.
>
> On Apr 30, 2014, at 11:29 AM, Ray Camden <ra...@adobe.com> wrote:
>
> > Any particular place? Sorry if obvious - but it would need to be a
> github repo multiple folks can edit. (Seems like that would be quicker than
> PRs imo.)
>
RE: Some pain points from our users :'(
Posted by Ray Camden <ra...@adobe.com>.
Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it.
________________________________________
From: Marcel Kinard <cm...@gmail.com>
Sent: Wednesday, April 30, 2014 10:41 AM
To: dev@cordova.apache.org
Subject: Re: Some pain points from our users :'(
How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this works, as long as the contributions are considered "trivial" by Apache standards. Otherwise pull requests to cordova-doc.git would be the [slower and more proper] way to go.
On Apr 30, 2014, at 11:29 AM, Ray Camden <ra...@adobe.com> wrote:
> Any particular place? Sorry if obvious - but it would need to be a github repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
Re: Some pain points from our users :'(
Posted by Marcel Kinard <cm...@gmail.com>.
How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this works, as long as the contributions are considered "trivial" by Apache standards. Otherwise pull requests to cordova-doc.git would be the [slower and more proper] way to go.
On Apr 30, 2014, at 11:29 AM, Ray Camden <ra...@adobe.com> wrote:
> Any particular place? Sorry if obvious - but it would need to be a github repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
RE: Some pain points from our users :'(
Posted by Ray Camden <ra...@adobe.com>.
Any particular place? Sorry if obvious - but it would need to be a github repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
________________________________________
From: Marcel Kinard <cm...@gmail.com>
Sent: Wednesday, April 30, 2014 10:22 AM
To: dev@cordova.apache.org
Subject: Re: Some pain points from our users :'(
How about using a short-term wiki page to create/grow the draft? Then it could migrate into cordova-docs.git.
Getting to the end of the Cordova docs with a working helloWorld, and then having signposts for the next places to go would be a significant gain in the perceived usability of Cordova. Ray, thank you!
On Apr 30, 2014, at 9:11 AM, Ray Camden <ra...@adobe.com> wrote:
> I'd love to take a stab at this. Where would be a good place for to post a draft that folks could edit and the Cordova team could just take it over when happy?
Re: Some pain points from our users :'(
Posted by Marcel Kinard <cm...@gmail.com>.
How about using a short-term wiki page to create/grow the draft? Then it could migrate into cordova-docs.git.
Getting to the end of the Cordova docs with a working helloWorld, and then having signposts for the next places to go would be a significant gain in the perceived usability of Cordova. Ray, thank you!
On Apr 30, 2014, at 9:11 AM, Ray Camden <ra...@adobe.com> wrote:
> I'd love to take a stab at this. Where would be a good place for to post a draft that folks could edit and the Cordova team could just take it over when happy?
RE: Some pain points from our users :'(
Posted by Ray Camden <ra...@adobe.com>.
I've had some recent discussions on this myself - and it came up at the open PhoneGap/Cordova session I hosted online a few days back. I'd love to take a stab at this. Where would be a good place for to post a draft that folks could edit and the Cordova team could just take it over when happy?
________________________________________
From: Joe Bowser <bo...@gmail.com>
Sent: Tuesday, April 29, 2014 3:12 PM
To: dev
Subject: Re: Some pain points from our users :'(
+1 to this post, who wants to take this on?
On Tue, Apr 29, 2014 at 12:22 PM, Joerg Holz <ho...@hamburg.de> wrote:
> I’m developing B2B-Apps (iOS and Android), using cordova.
>
> First of all, thank you for your great job. From release to release things are going easier and tidier.
>
> It is relatively easy for a beginner to start with cordova, but in a bigger project there are a lot of small jobs and decisions, which have to be made: The developer has to write clean html, js and css. Has to take care of: structure of the project, strategy to fall back and restart the project, testing, ui and ux, perhaps knowledge about a js-framework, sqlite, the plugin-things, …
>
> It needs a lot of time to get into all this stuff, learning the tricks and finding a good way for developing.
>
Re: Some pain points from our users :'(
Posted by Mike Billau <mi...@gmail.com>.
+1 for Joerg's comments. There has been a long outstanding bug to create a
"Next Steps" guide: https://issues.apache.org/jira/browse/CB-677
I know I personally do not "eat my own dogfood" enough, and I'm sure the
same can be said about a lot of us on this list. It can be pretty difficult
to even recognize that users are having the problems Joerg describes -
we've simply gotten so used to the project that it's hard to "take a step
back." This is why mining Stack Overflow and the Google group are huge.
Maybe we should send out a survey to the GG asking what kind of "next steps
/ growing pains" should be listed.
I don't think that we necessarily should be writing this documentation
ourselves though, but instead linking to various blog articles. See
Michael's comment in the JIRA item.
Joerg can you please copy your comments into the above JIRA issue?
On Tue, Apr 29, 2014 at 4:12 PM, Joe Bowser <bo...@gmail.com> wrote:
> +1 to this post, who wants to take this on?
>
> On Tue, Apr 29, 2014 at 12:22 PM, Joerg Holz <ho...@hamburg.de> wrote:
> > I’m developing B2B-Apps (iOS and Android), using cordova.
> >
> > First of all, thank you for your great job. From release to release
> things are going easier and tidier.
> >
> > It is relatively easy for a beginner to start with cordova, but in a
> bigger project there are a lot of small jobs and decisions, which have to
> be made: The developer has to write clean html, js and css. Has to take
> care of: structure of the project, strategy to fall back and restart the
> project, testing, ui and ux, perhaps knowledge about a js-framework,
> sqlite, the plugin-things, …
> >
> > It needs a lot of time to get into all this stuff, learning the tricks
> and finding a good way for developing.
> >
> > I know, it ist not your job to teach people how to do all this stuff,
> but it would be very helpfully, if there were a page in the documentation
> «The steps after the hello world example». Not a tutorial, just a few
> sentences and some links to going deeper into hybrid development.
> >
> > You are the developers of cordova, but there is a need for a bridge to
> the «customers» using cordova. (I’m still thinking about starting a blog,
> writing down my experiences.)
> >
> >
> > Some suggestions:
> >
> > – It would be helpful, if cordova could write a «create script», a
> special kind of log-file, in the project folder. In this create-script all
> steps for recreating the project are listed.
> >
> > – From the beginner side, it would be much easier to symlink the
> www-files in the root to the platform www-files.
> >
> > – There is a need to write in the documentation on which version of each
> platform cordova and the plugins are tested and running.
> >
> >
> > In my opinion, the most important software thing is, to solve the plugin
> situation, which are not in the core. I know, it ist not your job, but
> there is a need for other plugins and it is horrible to test them.
> >
> > Cordova is great, but it is not simple as it seems to be. I see a need
> to go more into the customer-view.
> >
> >
> >
> > Am 29.04.2014 um 20:02 schrieb Ian Clelland <ic...@chromium.org>:
> >
> >> Sorry, I'm a little late to the party here...
> >>
> >>
> >> On Mon, Apr 28, 2014 at 4:35 PM, Marcel Kinard <cm...@gmail.com>
> wrote:
> >>
> >>> How about this:
> >>>
> >>> 1) No API changes within a minor version bump.
> >>
> >>
> >> We try (maybe we could do better at this) to follow the guidelines at
> >> http://www.semver.org for all of the cordova subprojects, *except* for
> the
> >> main platform's version number, which we've kind of declared to be a
> >> "marketing" version number.
> >>
> >> According to semver, the rule should be "No API changes with only a
> patch
> >> version bump. Only backwards-combatible API changes with a minor version
> >> bump." In practice, this means that the patch version gets incremented
> with
> >> bug fixes, and any *new* APIs can be added with a minor version
> increment.
> >> Any backwards-incompatible changes *require* a major version bump.
> >>
> >>
> >>> For example, we're looking at some "consistency improvements" to the
> >>> globalization plugin that would change the return values. That should
> >>> trigger a major version bump, even if the signatures/parms don't
> change.
> >>
> >>
> >> If the API signatures don't change, then we'd have to consider what *is*
> >> changing? If it's just the output, and it's incorrect in version A and
> >> correct in version B, then that sounds like a bug fix. If the output is
> >> different in a meaningful way then maybe that's minor, maybe major. (I
> >> would suggest that it's minor only if the output is definitely *better*
> in
> >> every case with the new version, but can still be consumed in exactly
> the
> >> same way)
> >>
> >>
> >>> As a consumer of Cordova, you should be able to have some confidence
> that
> >>> if there isn't a major version bump, you shouldn't need to change your
> >>> calling code.
> >>>
> >>>
> >> Absolutely. If any change to client code is required, there should be a
> >> major version bump. (Within reason: any bug could be depended on by
> >> someone; see https://xkcd.com/1172/)
> >>
> >>
> >>
> >>> 2) When doing an upgrade of plugins or platform, if there is a major
> >>> version bump to any of those components, the CLI should make it really
> >>> clear (a warning) that there may be a breaking change(s) and give them
> the
> >>> opportunity to abort the upgrade.
> >>>
> >>
> >> +1. We really need this. Maybe, like Debian, an upgrade should only ever
> >> upgrade within the same major release, and a harder upgrade command
> would
> >> be required for upgrading the major.
> >>
> >> Of course, this is all wishful thinking right now, since there's no
> upgrade
> >> command at all. The "upgrade" path is currently "remove plugin; re-add
> >> plugin", and I don't think that that flow should ever keep old metadata
> >> around.
> >>
> >>
> >>> 3) Keep the Upgrading Guides in the docs complete. So if they want to
> look
> >>> at what needs to change, these docs should at least give them a feel
> for
> >>> the order of magnitude, or better yet exactly what would be required.
> >>>
> >>> We are doing 1 & 3 already, correct?
> >>>
> >>> On Apr 28, 2014, at 2:49 PM, Josh Soref <js...@blackberry.com> wrote:
> >>>
> >>>> Shazron wrote:
> >>>>
> >>>>> See:
> https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
> >>>>
> >>>> While I haven't written it, I've contemplated the metadata required
> for
> >>> an
> >>>> update check that could tell you when a given api breaks.
> >>>>
> >>>>> because the API for device.platform changed and returned "ios"
> instead
> >>>>> of "iPhone"/"iPad",
> >>>>
> >>>> In principle, this would have been flagged to discourage updating the
> >>>> plugin, and in theory a solver could have identified the last version
> >>> from
> >>>> before this break.
> >>>
> >
> > --------------------------------------------------------
> > Jörg Holz | +49-175-640 35 80
> > holz@hamburg.de
> >
> > NEU: doreport - die Reportingsoftware:
> > http://www.doreport.de
> > --------------------------------------------------------
> >
>
Re: Some pain points from our users :'(
Posted by Michal Mocny <mm...@chromium.org>.
On Tue, Apr 29, 2014 at 4:12 PM, Joe Bowser <bo...@gmail.com> wrote:
> +1 to this post, who wants to take this on?
>
> On Tue, Apr 29, 2014 at 12:22 PM, Joerg Holz <ho...@hamburg.de> wrote:
> > I’m developing B2B-Apps (iOS and Android), using cordova.
> >
> > First of all, thank you for your great job. From release to release
> things are going easier and tidier.
>
Thank you.
> >
> > It is relatively easy for a beginner to start with cordova, but in a
> bigger project there are a lot of small jobs and decisions, which have to
> be made: The developer has to write clean html, js and css. Has to take
> care of: structure of the project, strategy to fall back and restart the
> project, testing, ui and ux, perhaps knowledge about a js-framework,
> sqlite, the plugin-things, …
> >
> > It needs a lot of time to get into all this stuff, learning the tricks
> and finding a good way for developing.
> >
> > I know, it ist not your job to teach people how to do all this stuff,
> but it would be very helpfully, if there were a page in the documentation
> «The steps after the hello world example». Not a tutorial, just a few
> sentences and some links to going deeper into hybrid development.
> >
> > You are the developers of cordova, but there is a need for a bridge to
> the «customers» using cordova. (I’m still thinking about starting a blog,
> writing down my experiences.)
> >
> >
> > Some suggestions:
> >
> > – It would be helpful, if cordova could write a «create script», a
> special kind of log-file, in the project folder. In this create-script all
> steps for recreating the project are listed.
>
I think this is being addressed. I suspect we are 1-2 releases away from a
CLI workflow where in-place upgrades / git sharing of projects / workspace
recreation / in-place plugin creation, etc, are all very common sense and
happen exactly the way you should expect.
> >
> > – From the beginner side, it would be much easier to symlink the
> www-files in the root to the platform www-files.
>
We try. There are already some virtual links created inside the IDE's
(eclipse, xcode) to root www/, but it isn't perfect. Plugin files aren't
linked. If you actually look at the platforms/ dir, you won't find links
because the build systems require physical files.
The best way to address this problem is to continue to replace the need to
modify platforms/ directly, and make that workflow obvious & enjoyable for
developers.
> >
> > – There is a need to write in the documentation on which version of each
> platform cordova and the plugins are tested and running.
>
This is somewhat addressed for platforms, but our plugin version matching
has sucked. We've mostly gotten away with this because most of the API's
haven't changed significantly, but where they have changed (e.g. File) the
experience has been terrible. This is a bug, that isn't being worked on
enough.
> >
> >
> > In my opinion, the most important software thing is, to solve the plugin
> situation, which are not in the core. I know, it ist not your job, but
> there is a need for other plugins and it is horrible to test them.
>
Do you mean the quality or workflow? I think we should make plugin
development / upgrades / publishing easier, but I'm not sure we can solve
the quality problem.
> >
> > Cordova is great, but it is not simple as it seems to be. I see a need
> to go more into the customer-view.
>
>
> >
> >
> > Am 29.04.2014 um 20:02 schrieb Ian Clelland <ic...@chromium.org>:
> >
> >> Sorry, I'm a little late to the party here...
> >>
> >>
> >> On Mon, Apr 28, 2014 at 4:35 PM, Marcel Kinard <cm...@gmail.com>
> wrote:
> >>
> >>> How about this:
> >>>
> >>> 1) No API changes within a minor version bump.
> >>
> >>
> >> We try (maybe we could do better at this) to follow the guidelines at
> >> http://www.semver.org for all of the cordova subprojects, *except* for
> the
> >> main platform's version number, which we've kind of declared to be a
> >> "marketing" version number.
> >>
> >> According to semver, the rule should be "No API changes with only a
> patch
> >> version bump. Only backwards-combatible API changes with a minor version
> >> bump." In practice, this means that the patch version gets incremented
> with
> >> bug fixes, and any *new* APIs can be added with a minor version
> increment.
> >> Any backwards-incompatible changes *require* a major version bump.
> >>
> >>
> >>> For example, we're looking at some "consistency improvements" to the
> >>> globalization plugin that would change the return values. That should
> >>> trigger a major version bump, even if the signatures/parms don't
> change.
> >>
> >>
> >> If the API signatures don't change, then we'd have to consider what *is*
> >> changing? If it's just the output, and it's incorrect in version A and
> >> correct in version B, then that sounds like a bug fix. If the output is
> >> different in a meaningful way then maybe that's minor, maybe major. (I
> >> would suggest that it's minor only if the output is definitely *better*
> in
> >> every case with the new version, but can still be consumed in exactly
> the
> >> same way)
> >>
> >>
> >>> As a consumer of Cordova, you should be able to have some confidence
> that
> >>> if there isn't a major version bump, you shouldn't need to change your
> >>> calling code.
> >>>
> >>>
> >> Absolutely. If any change to client code is required, there should be a
> >> major version bump. (Within reason: any bug could be depended on by
> >> someone; see https://xkcd.com/1172/)
> >>
> >>
> >>
> >>> 2) When doing an upgrade of plugins or platform, if there is a major
> >>> version bump to any of those components, the CLI should make it really
> >>> clear (a warning) that there may be a breaking change(s) and give them
> the
> >>> opportunity to abort the upgrade.
> >>>
> >>
> >> +1. We really need this. Maybe, like Debian, an upgrade should only ever
> >> upgrade within the same major release, and a harder upgrade command
> would
> >> be required for upgrading the major.
> >>
> >> Of course, this is all wishful thinking right now, since there's no
> upgrade
> >> command at all. The "upgrade" path is currently "remove plugin; re-add
> >> plugin", and I don't think that that flow should ever keep old metadata
> >> around.
> >>
> >>
> >>> 3) Keep the Upgrading Guides in the docs complete. So if they want to
> look
> >>> at what needs to change, these docs should at least give them a feel
> for
> >>> the order of magnitude, or better yet exactly what would be required.
> >>>
> >>> We are doing 1 & 3 already, correct?
> >>>
> >>> On Apr 28, 2014, at 2:49 PM, Josh Soref <js...@blackberry.com> wrote:
> >>>
> >>>> Shazron wrote:
> >>>>
> >>>>> See:
> https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
> >>>>
> >>>> While I haven't written it, I've contemplated the metadata required
> for
> >>> an
> >>>> update check that could tell you when a given api breaks.
> >>>>
> >>>>> because the API for device.platform changed and returned "ios"
> instead
> >>>>> of "iPhone"/"iPad",
> >>>>
> >>>> In principle, this would have been flagged to discourage updating the
> >>>> plugin, and in theory a solver could have identified the last version
> >>> from
> >>>> before this break.
> >>>
> >
> > --------------------------------------------------------
> > Jörg Holz | +49-175-640 35 80
> > holz@hamburg.de
> >
> > NEU: doreport - die Reportingsoftware:
> > http://www.doreport.de
> > --------------------------------------------------------
> >
>
Re: Some pain points from our users :'(
Posted by Joe Bowser <bo...@gmail.com>.
+1 to this post, who wants to take this on?
On Tue, Apr 29, 2014 at 12:22 PM, Joerg Holz <ho...@hamburg.de> wrote:
> I’m developing B2B-Apps (iOS and Android), using cordova.
>
> First of all, thank you for your great job. From release to release things are going easier and tidier.
>
> It is relatively easy for a beginner to start with cordova, but in a bigger project there are a lot of small jobs and decisions, which have to be made: The developer has to write clean html, js and css. Has to take care of: structure of the project, strategy to fall back and restart the project, testing, ui and ux, perhaps knowledge about a js-framework, sqlite, the plugin-things, …
>
> It needs a lot of time to get into all this stuff, learning the tricks and finding a good way for developing.
>
> I know, it ist not your job to teach people how to do all this stuff, but it would be very helpfully, if there were a page in the documentation «The steps after the hello world example». Not a tutorial, just a few sentences and some links to going deeper into hybrid development.
>
> You are the developers of cordova, but there is a need for a bridge to the «customers» using cordova. (I’m still thinking about starting a blog, writing down my experiences.)
>
>
> Some suggestions:
>
> – It would be helpful, if cordova could write a «create script», a special kind of log-file, in the project folder. In this create-script all steps for recreating the project are listed.
>
> – From the beginner side, it would be much easier to symlink the www-files in the root to the platform www-files.
>
> – There is a need to write in the documentation on which version of each platform cordova and the plugins are tested and running.
>
>
> In my opinion, the most important software thing is, to solve the plugin situation, which are not in the core. I know, it ist not your job, but there is a need for other plugins and it is horrible to test them.
>
> Cordova is great, but it is not simple as it seems to be. I see a need to go more into the customer-view.
>
>
>
> Am 29.04.2014 um 20:02 schrieb Ian Clelland <ic...@chromium.org>:
>
>> Sorry, I'm a little late to the party here...
>>
>>
>> On Mon, Apr 28, 2014 at 4:35 PM, Marcel Kinard <cm...@gmail.com> wrote:
>>
>>> How about this:
>>>
>>> 1) No API changes within a minor version bump.
>>
>>
>> We try (maybe we could do better at this) to follow the guidelines at
>> http://www.semver.org for all of the cordova subprojects, *except* for the
>> main platform's version number, which we've kind of declared to be a
>> "marketing" version number.
>>
>> According to semver, the rule should be "No API changes with only a patch
>> version bump. Only backwards-combatible API changes with a minor version
>> bump." In practice, this means that the patch version gets incremented with
>> bug fixes, and any *new* APIs can be added with a minor version increment.
>> Any backwards-incompatible changes *require* a major version bump.
>>
>>
>>> For example, we're looking at some "consistency improvements" to the
>>> globalization plugin that would change the return values. That should
>>> trigger a major version bump, even if the signatures/parms don't change.
>>
>>
>> If the API signatures don't change, then we'd have to consider what *is*
>> changing? If it's just the output, and it's incorrect in version A and
>> correct in version B, then that sounds like a bug fix. If the output is
>> different in a meaningful way then maybe that's minor, maybe major. (I
>> would suggest that it's minor only if the output is definitely *better* in
>> every case with the new version, but can still be consumed in exactly the
>> same way)
>>
>>
>>> As a consumer of Cordova, you should be able to have some confidence that
>>> if there isn't a major version bump, you shouldn't need to change your
>>> calling code.
>>>
>>>
>> Absolutely. If any change to client code is required, there should be a
>> major version bump. (Within reason: any bug could be depended on by
>> someone; see https://xkcd.com/1172/)
>>
>>
>>
>>> 2) When doing an upgrade of plugins or platform, if there is a major
>>> version bump to any of those components, the CLI should make it really
>>> clear (a warning) that there may be a breaking change(s) and give them the
>>> opportunity to abort the upgrade.
>>>
>>
>> +1. We really need this. Maybe, like Debian, an upgrade should only ever
>> upgrade within the same major release, and a harder upgrade command would
>> be required for upgrading the major.
>>
>> Of course, this is all wishful thinking right now, since there's no upgrade
>> command at all. The "upgrade" path is currently "remove plugin; re-add
>> plugin", and I don't think that that flow should ever keep old metadata
>> around.
>>
>>
>>> 3) Keep the Upgrading Guides in the docs complete. So if they want to look
>>> at what needs to change, these docs should at least give them a feel for
>>> the order of magnitude, or better yet exactly what would be required.
>>>
>>> We are doing 1 & 3 already, correct?
>>>
>>> On Apr 28, 2014, at 2:49 PM, Josh Soref <js...@blackberry.com> wrote:
>>>
>>>> Shazron wrote:
>>>>
>>>>> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
>>>>
>>>> While I haven't written it, I've contemplated the metadata required for
>>> an
>>>> update check that could tell you when a given api breaks.
>>>>
>>>>> because the API for device.platform changed and returned "ios" instead
>>>>> of "iPhone"/"iPad",
>>>>
>>>> In principle, this would have been flagged to discourage updating the
>>>> plugin, and in theory a solver could have identified the last version
>>> from
>>>> before this break.
>>>
>
> --------------------------------------------------------
> Jörg Holz | +49-175-640 35 80
> holz@hamburg.de
>
> NEU: doreport - die Reportingsoftware:
> http://www.doreport.de
> --------------------------------------------------------
>
Re: Some pain points from our users :'(
Posted by Joerg Holz <ho...@hamburg.de>.
I’m developing B2B-Apps (iOS and Android), using cordova.
First of all, thank you for your great job. From release to release things are going easier and tidier.
It is relatively easy for a beginner to start with cordova, but in a bigger project there are a lot of small jobs and decisions, which have to be made: The developer has to write clean html, js and css. Has to take care of: structure of the project, strategy to fall back and restart the project, testing, ui and ux, perhaps knowledge about a js-framework, sqlite, the plugin-things, …
It needs a lot of time to get into all this stuff, learning the tricks and finding a good way for developing.
I know, it ist not your job to teach people how to do all this stuff, but it would be very helpfully, if there were a page in the documentation «The steps after the hello world example». Not a tutorial, just a few sentences and some links to going deeper into hybrid development.
You are the developers of cordova, but there is a need for a bridge to the «customers» using cordova. (I’m still thinking about starting a blog, writing down my experiences.)
Some suggestions:
– It would be helpful, if cordova could write a «create script», a special kind of log-file, in the project folder. In this create-script all steps for recreating the project are listed.
– From the beginner side, it would be much easier to symlink the www-files in the root to the platform www-files.
– There is a need to write in the documentation on which version of each platform cordova and the plugins are tested and running.
In my opinion, the most important software thing is, to solve the plugin situation, which are not in the core. I know, it ist not your job, but there is a need for other plugins and it is horrible to test them.
Cordova is great, but it is not simple as it seems to be. I see a need to go more into the customer-view.
Am 29.04.2014 um 20:02 schrieb Ian Clelland <ic...@chromium.org>:
> Sorry, I'm a little late to the party here...
>
>
> On Mon, Apr 28, 2014 at 4:35 PM, Marcel Kinard <cm...@gmail.com> wrote:
>
>> How about this:
>>
>> 1) No API changes within a minor version bump.
>
>
> We try (maybe we could do better at this) to follow the guidelines at
> http://www.semver.org for all of the cordova subprojects, *except* for the
> main platform's version number, which we've kind of declared to be a
> "marketing" version number.
>
> According to semver, the rule should be "No API changes with only a patch
> version bump. Only backwards-combatible API changes with a minor version
> bump." In practice, this means that the patch version gets incremented with
> bug fixes, and any *new* APIs can be added with a minor version increment.
> Any backwards-incompatible changes *require* a major version bump.
>
>
>> For example, we're looking at some "consistency improvements" to the
>> globalization plugin that would change the return values. That should
>> trigger a major version bump, even if the signatures/parms don't change.
>
>
> If the API signatures don't change, then we'd have to consider what *is*
> changing? If it's just the output, and it's incorrect in version A and
> correct in version B, then that sounds like a bug fix. If the output is
> different in a meaningful way then maybe that's minor, maybe major. (I
> would suggest that it's minor only if the output is definitely *better* in
> every case with the new version, but can still be consumed in exactly the
> same way)
>
>
>> As a consumer of Cordova, you should be able to have some confidence that
>> if there isn't a major version bump, you shouldn't need to change your
>> calling code.
>>
>>
> Absolutely. If any change to client code is required, there should be a
> major version bump. (Within reason: any bug could be depended on by
> someone; see https://xkcd.com/1172/)
>
>
>
>> 2) When doing an upgrade of plugins or platform, if there is a major
>> version bump to any of those components, the CLI should make it really
>> clear (a warning) that there may be a breaking change(s) and give them the
>> opportunity to abort the upgrade.
>>
>
> +1. We really need this. Maybe, like Debian, an upgrade should only ever
> upgrade within the same major release, and a harder upgrade command would
> be required for upgrading the major.
>
> Of course, this is all wishful thinking right now, since there's no upgrade
> command at all. The "upgrade" path is currently "remove plugin; re-add
> plugin", and I don't think that that flow should ever keep old metadata
> around.
>
>
>> 3) Keep the Upgrading Guides in the docs complete. So if they want to look
>> at what needs to change, these docs should at least give them a feel for
>> the order of magnitude, or better yet exactly what would be required.
>>
>> We are doing 1 & 3 already, correct?
>>
>> On Apr 28, 2014, at 2:49 PM, Josh Soref <js...@blackberry.com> wrote:
>>
>>> Shazron wrote:
>>>
>>>> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
>>>
>>> While I haven't written it, I've contemplated the metadata required for
>> an
>>> update check that could tell you when a given api breaks.
>>>
>>>> because the API for device.platform changed and returned "ios" instead
>>>> of "iPhone"/"iPad",
>>>
>>> In principle, this would have been flagged to discourage updating the
>>> plugin, and in theory a solver could have identified the last version
>> from
>>> before this break.
>>
--------------------------------------------------------
Jörg Holz | +49-175-640 35 80
holz@hamburg.de
NEU: doreport - die Reportingsoftware:
http://www.doreport.de
--------------------------------------------------------
Re: Some pain points from our users :'(
Posted by Ian Clelland <ic...@chromium.org>.
Sorry, I'm a little late to the party here...
On Mon, Apr 28, 2014 at 4:35 PM, Marcel Kinard <cm...@gmail.com> wrote:
> How about this:
>
> 1) No API changes within a minor version bump.
We try (maybe we could do better at this) to follow the guidelines at
http://www.semver.org for all of the cordova subprojects, *except* for the
main platform's version number, which we've kind of declared to be a
"marketing" version number.
According to semver, the rule should be "No API changes with only a patch
version bump. Only backwards-combatible API changes with a minor version
bump." In practice, this means that the patch version gets incremented with
bug fixes, and any *new* APIs can be added with a minor version increment.
Any backwards-incompatible changes *require* a major version bump.
> For example, we're looking at some "consistency improvements" to the
> globalization plugin that would change the return values. That should
> trigger a major version bump, even if the signatures/parms don't change.
If the API signatures don't change, then we'd have to consider what *is*
changing? If it's just the output, and it's incorrect in version A and
correct in version B, then that sounds like a bug fix. If the output is
different in a meaningful way then maybe that's minor, maybe major. (I
would suggest that it's minor only if the output is definitely *better* in
every case with the new version, but can still be consumed in exactly the
same way)
> As a consumer of Cordova, you should be able to have some confidence that
> if there isn't a major version bump, you shouldn't need to change your
> calling code.
>
>
Absolutely. If any change to client code is required, there should be a
major version bump. (Within reason: any bug could be depended on by
someone; see https://xkcd.com/1172/)
> 2) When doing an upgrade of plugins or platform, if there is a major
> version bump to any of those components, the CLI should make it really
> clear (a warning) that there may be a breaking change(s) and give them the
> opportunity to abort the upgrade.
>
+1. We really need this. Maybe, like Debian, an upgrade should only ever
upgrade within the same major release, and a harder upgrade command would
be required for upgrading the major.
Of course, this is all wishful thinking right now, since there's no upgrade
command at all. The "upgrade" path is currently "remove plugin; re-add
plugin", and I don't think that that flow should ever keep old metadata
around.
> 3) Keep the Upgrading Guides in the docs complete. So if they want to look
> at what needs to change, these docs should at least give them a feel for
> the order of magnitude, or better yet exactly what would be required.
>
> We are doing 1 & 3 already, correct?
>
> On Apr 28, 2014, at 2:49 PM, Josh Soref <js...@blackberry.com> wrote:
>
> > Shazron wrote:
> >
> >> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
> >
> > While I haven't written it, I've contemplated the metadata required for
> an
> > update check that could tell you when a given api breaks.
> >
> >> because the API for device.platform changed and returned "ios" instead
> >> of "iPhone"/"iPad",
> >
> > In principle, this would have been flagged to discourage updating the
> > plugin, and in theory a solver could have identified the last version
> from
> > before this break.
>
Re: Some pain points from our users :'(
Posted by Josh Soref <js...@blackberry.com>.
Marcel Kinard wrote:
>How about this:
>1) No API changes within a minor version bump. For example, we're looking
>at some "consistency improvements" to the globalization plugin that would
>change the return values. That should trigger a major version bump, even
>if the signatures/parms don't change. As a consumer of Cordova, you
>should be able to have some confidence that if there isn't a major
>version bump, you shouldn't need to change your calling code.
This is again the sort of thing I'm talking about, but it's pretty hard to
do with a single number, and mostly useless. OTOH, with sufficient
metadata to describe specific changes, it should work reasonably well.
The problem is that there's *very* little that you can do to code which
won't change someone's code. https://xkcd.com/1172/
If I fix the spelling of some output, it could break someone's parser. If
I fix the spelling in some documentation, it could break someone's parser,
or their test. If I change an image, it could break anything which expects
a fixed size, fixed checksum, or fixed byte.
A number really doesn't help people. The number will be "bigger", and
probably "much bigger", what people need to know is "does this affect me".
And ideally we can answer that for most cases. If I add a constant which
is totally optional, then we can say "this probably won't affect you". If
I add a constant which is needed to get behavior similar to past behavior,
we can say "not having this constant in your code and using code before X
will probably need a rethink".
We're at the end of a release cycle, when we finish it, I'll try to post
my metadata thoughts to the wiki.
>2) When doing an upgrade of plugins or platform, if there is a major
>version bump to any of those components, the CLI should make it really
>clear (a warning) that there may be a breaking change(s) and give them
>the opportunity to abort the upgrade.
Last I checked, there was no way to update plugins, only remove them and
add them again. But yes, my proposal would be a step to enable such a
warning. It requires collecting metadata - which could be a problem.
>3) Keep the Upgrading Guides in the docs complete. So if they want to
>look at what needs to change, these docs should at least give them a feel
>for the order of magnitude, or better yet exactly what would be required.
>
>We are doing 1 & 3 already, correct?
I'm pretty sure we aren't doing a good job at 3.
I don't use plugins much. I can say that it's pretty easy to not realize
you've broken something, that happens a lot. Cordova-blackberry broke a
whole bunch of (very poorly written) plugins because it fixed a bug in the
exec bridge (the bridge is supposed to be async, but it wasn't, we made it
async as per spec, but any plugin that assumed it was sync suddenly broke).
A checklist which requires you to ask / consider metadata is one way that
I hope we could improve this.
Re: Some pain points from our users :'(
Posted by Brian LeRoux <b...@brian.io>.
Listening to our developer community is important but it should come with
the balance that we do make decisions for a good reason, and as Joe
mentoined, this is open source so anyone is free to contribute. The
spectrum of contribution includes complaint though we tend to prefer those
in the form of Jira issues.
Anyhow, those changes mentioned by Todd before where either necessary and
he just didn't have the context to know that, arrived at by public
consensus, or manifest bugs which we fixed.
If this thread was an issue I'd personally mark it as closed.
On Mon, Apr 28, 2014 at 1:35 PM, Marcel Kinard <cm...@gmail.com> wrote:
> How about this:
>
> 1) No API changes within a minor version bump. For example, we're looking
> at some "consistency improvements" to the globalization plugin that would
> change the return values. That should trigger a major version bump, even if
> the signatures/parms don't change. As a consumer of Cordova, you should be
> able to have some confidence that if there isn't a major version bump, you
> shouldn't need to change your calling code.
>
> 2) When doing an upgrade of plugins or platform, if there is a major
> version bump to any of those components, the CLI should make it really
> clear (a warning) that there may be a breaking change(s) and give them the
> opportunity to abort the upgrade.
>
> 3) Keep the Upgrading Guides in the docs complete. So if they want to look
> at what needs to change, these docs should at least give them a feel for
> the order of magnitude, or better yet exactly what would be required.
>
> We are doing 1 & 3 already, correct?
>
> On Apr 28, 2014, at 2:49 PM, Josh Soref <js...@blackberry.com> wrote:
>
> > Shazron wrote:
> >
> >> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
> >
> > While I haven't written it, I've contemplated the metadata required for
> an
> > update check that could tell you when a given api breaks.
> >
> >> because the API for device.platform changed and returned "ios" instead
> >> of "iPhone"/"iPad",
> >
> > In principle, this would have been flagged to discourage updating the
> > plugin, and in theory a solver could have identified the last version
> from
> > before this break.
>
Re: Some pain points from our users :'(
Posted by Marcel Kinard <cm...@gmail.com>.
How about this:
1) No API changes within a minor version bump. For example, we're looking at some "consistency improvements" to the globalization plugin that would change the return values. That should trigger a major version bump, even if the signatures/parms don't change. As a consumer of Cordova, you should be able to have some confidence that if there isn't a major version bump, you shouldn't need to change your calling code.
2) When doing an upgrade of plugins or platform, if there is a major version bump to any of those components, the CLI should make it really clear (a warning) that there may be a breaking change(s) and give them the opportunity to abort the upgrade.
3) Keep the Upgrading Guides in the docs complete. So if they want to look at what needs to change, these docs should at least give them a feel for the order of magnitude, or better yet exactly what would be required.
We are doing 1 & 3 already, correct?
On Apr 28, 2014, at 2:49 PM, Josh Soref <js...@blackberry.com> wrote:
> Shazron wrote:
>
>> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
>
> While I haven't written it, I've contemplated the metadata required for an
> update check that could tell you when a given api breaks.
>
>> because the API for device.platform changed and returned "ios" instead
>> of "iPhone"/"iPad",
>
> In principle, this would have been flagged to discourage updating the
> plugin, and in theory a solver could have identified the last version from
> before this break.
Re: Some pain points from our users :'(
Posted by Josh Soref <js...@blackberry.com>.
Shazron wrote:
>See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
While I haven't written it, I've contemplated the metadata required for an
update check that could tell you when a given api breaks.
> because the API for device.platform changed and returned "ios" instead
>of "iPhone"/"iPad",
In principle, this would have been flagged to discourage updating the
plugin, and in theory a solver could have identified the last version from
before this break.
> Cordova/Phonegap docs where no help, because the version 3.4.0 version
>of the docs has broken links for all the plugins api docs.
This is a release process issue. We shouldn't have allowed the release to
happen w/ this broken. At least one of Edge or release-version should
always work.
> I then installed the "status bar" plugin for the ios 7 status bar. This
>plugin didn't work either. I always get an error in the XCode console
>that one or the other plugin does not exist or isn't cdv plugin...
I think this was the Xcode 5.1 bug, which I think we should have (process)
released the fix for sooner.