Chart 7.x-2.x Release

Thank you Brad for joining this conversion! If you haven't done so yet, please checkout #2368793: Chart 2.0 to understand the big picture of what I'm trying to achieve. My comment #3 in that issue (which I only added earlier today) also explains how "this issue" fits in that big picture. I hope it also explains my growing concern (am i really the only one?) about the April 2014 deadline you mentioned. If it's still not clear to anybody, I am trying to approach a solution to it by assuming "will" instead of "may" in your 2nd phrase in your previous comment.

About your 1st phrase (patches adding new functionality): you have a valid point about that. But understand that I don't have the background/experience like you must have with the chart module. So sometimes it's hard for me to judge "is this a fix or a new functionality". Therefor I've not used that judgement to yes/no consider existing patches, for me it was only like "ok, this issue contains something (like a patch) to be considered for inclusion". A variation of the approach I suggested could be to move issues with patches containing "new functionality" to something like another 7.x-1.3 version, which at this time could be considered as "if time permits" (though time is running out ...).

If I may say, there is another challenge to be addressed: how do I find the relationship between a patch in an issue, and the commit message that confirms it was yes or no actually committed? So far I've not been able to find any relationships like that, probably because the issue IDs were not included in the commit messages I've been searching for (hence they don't show up in the issue comments). Suggestions about how to find the answer to my question here? If you have some type of info somewhere via which you can easily find the answer to this question, please share / forward it. As a variation: update the corresponding commit messages by including the issue reference in it, eventually combined with the comment id also (which of course will make the commit show up in that issue).

To answer your 3rd question: read my comment (as I mentioned above in this comment here) from earlier today: I don't know YET, but I'm confident to find the answer soon ... hopefully with the "support" and "backing" from the chart users ... and people like you (and other maintainers). If I don't succeed, I'll think of it like "worse then not succeeding .. is to not have tried". Or should I say "many people have dreams, only a few wake up and start working on them"?

Brad, thank you for this additional clarification, that already helps a lot! Referring to your comment 12 in #2368793: Chart 2.0, I suggest to rename the title of this issue to Chart 7.x-1.3 Release, to create room for a NEW issue titled Chart 7.x-1.2 Release. The content of the "new" Chart 7.x-1.2 Release is then as you suggested in that comment, i.e. the current Chart 7.x-1.dev version, together with that hook_requirements addition. Afterwards, I'd be happy to re-verify the current child issues of this issue to answer the question "is that OK now in the new Chart 7.x-1.2 Release? If not it might make it into something like that Chart 7.x-1.3 Release". Let me know your thoughts on this please.

About your "The best use ..." parg: such 'procedure' is indeed part of what I'm thinking of, and charts seems like an obvious candidate. But "another module" might be offered as an alternative to consider. In the end the "user" should have choices to pick from, probably using criteria like features, supported libraries, licenses, etc. And the fragmentation one can see now via the comparison of charting modules (which by the way is not a graph .. yet), was one of "my" reasons why I actually started that comparison: I was confused by all the charting related modules to pick from. I kept digging and digging (I still am ...). And then I discovered the "chart" module (most installs, about end of live, etc). At first I couldn't believe what I saw, I checked it again, and then I decided to create issue #2368793: Chart 2.0. But soon after that I realised that somebody better started doing something to resolve what I now call the chart-legacy (trying to find some solution for those 26K users). So I started digging in the issue queue (did you notice??? Sorry for all the eMails triggered to anybody who is following the issue queue!). And that's how I then started to think of some type of granular approach, via issues like this one that I created. I still don't like the fact that many issue creators have not gotten back with answers to issues I classified as "maintainer needs more info", but hey that's how things work in drupal issue queues, right? Soon I plan to start closing quite a few of those issues, with something like "close due to lack of feedback, assuming it is no longer an issue" (hope you'll agree with me on that).

And yes I plan to start working heavily oin the chart namespace. May I say "I already started .... even though not even 1 commit so far"?

About convincing other module maintainers: if things turn out as you suggested, that would be great! However, I can understand that there will still be maintainers who for whatever reason want to continue their own module. Which is fine for me, though I'll perceive it as a kind of waste of resources. Also note that my ambition is NOT to become the chart "owner". My current co-maintainer status is fine for me. If however some day I'm asked to become the "owner", for whatever reasons, I'll probably accept to do so. Anybody interested in a real world cases of what I've been doing recently as co-maintainer of another module: checkout the forena module, or its issue queue, or talk to its owner (David), or its community docu, or ... my comparison of charting modules (which I started in the context of forena).

About your last parg: I'm NOT surprised that there are still so much sites. And just in case you don't realise: the number that keeps growing (about 1000 since last month, go figure!), is the highest for all available charting modules also, though charts is doing a fairly good job already to grow with similar amounts. Even though I cannot proof it, I'm wondering if the continued growth can be explained by the fact that the charts module is only available as a "rc1" version (already since March 2014 ...), due to which chart users might keep waiting (or use it as an excuse?) and stick with the chart module. Another reason might be "OK, let's assume I want to go from chart to charts ... where is the docu about how to do so ... without starting all my charts from scratch again?".

About setting this module unsupported as you had planned for: before creating issue #2368793: Chart 2.0, I had done quite some research in the chart issue queue. That's how I noticed that soon the chart module might become unsupported.

Brad, that seems to me like an appropriate warning "at this time". However, depending on how things evolve between now and whatever deadline, I think it would help if we have something that gives us a little more flexibility, so that we can dynamically adapt that warning whenever needed (without forcing another chart update in between).

So how about reworking your proposal by moving part of it to a new chart issue (wth content as you suggested), i.e. issue nr 2376179. And combine that with a reduced version of it as the warning message, with some kind of link (pointer) to the new 2376179 issue? Here is an attempt to illustrate what I think could work (maybe you can condense it even a bit further):

The Google Chart Tools: Image Charts API is expected to shutdown as of April 20, 2015, which will cause this chart module to not function anymore. Refer to issue 2376179 for possible alternatives to consider.

Regarding your last parg (specifying a date, etc): for now I'd use a phrasing like "around April 20, 2015 the chart module might become unsupported, and further downloads might be disabled". I'd add such phrasing in the 2376179 issue, so that it can be dynamically adapted whenever needed (for similar reasons).

Brad (oeps ... eosrei ... sorry friend, must be cultural differences ...), et all: at this point I'm not decided yet ...

• Reason 1 is because of my PS in #24 in #2368793: Chart 2.0. I guess @Quicksketch (Nate) is busy with other things these days? Maybe you can contact him (again) to ask for his opinion regarding the #19, #20, #21, #22, #23 ?
• Reason 2 is because if "we" (which I hope to be more then just me ...) decide to go for some type of merger of chart and charts, it really doesn't matter to me which codebase we work with, as long as we achieve our goal.

However I also think that in order to move forward (asap) with that hook_requirements() thing in 7.x-1.2 we're considering here (from #10 on), it appears to me that at least this still needs to happen in the chart codebase/namespace, for sure not (yet) anywhere in charts. And after we decided if we continue with chart, charts or both, we'll then (and only then) apply some other (minor) update corresponding to that decision. By now including some type of pointer to some special issue as I suggested in #11, we do not have to touch the 7.x-1.2 version anymore to just communicate that decision (which is why I prefer that approach).

Hope this answers your question, if not either get back to it, or otherwise just go for some approach that you (one of the current chart experts, right?) decide for. For me at this time the most important thing is that this hook_requirements thing starts showing up in all those +20K existing chart-7.x sites, preferably by yesterday already ... And this by making the 7.x-1.2 release as the currently recommended release, combined with marking the 7.x-1.1 release as unsupported (and no longer available for download). If those sites then still don't upgrade to it soon, at least "we" can say we did our best to make them aware of the April 2015 deadline.

Friendly reminder: what about the suggested rename of the title of this issue as in parg 1 of #9 ? Don't think you answered that anywhere so far ...

Now we are cooking! Thank you Brad!

Give me a little time to create that new 7.x-1.3 issue (probably tomorrow). It should somehow reflect the options we're currently considering, and probably some link to this issue. After you then review/refine it where needed, we have everything we need for that 7.x-1.2. And by the way too bad for those "few" sites who don't seem to update to the latest recommended releases. Those who do ate the ones what I think we should try to target.

Issue #2376179: Chart 7.x-3.x Release is created now. And I updated the issue ID in #11 to point to it.

I also moved quite some child issues from this issue to the new issue. About the remaining child issues of this issue: those in status closed(fixed) seem OK to me (they are already in the current DEV version). All other issues needs further review/verification.

Seems that there are no objections to what Brad (eosrei) suggested in #2368793-15: Chart 2.0. Together with my #17 above, it appears to me that we have everything needed now to go for that new Chart 7.x-1.2 release ...

Brad and/or Jimmy (not sure who to ask), is there anything blocking us from moving forward on this issue? Per #2368793-1: Chart 2.0 (last phrase in it), I'm a kind of stuck on "this" release, no? And April 2015 is coming closer and closer ...

Dear all, I'm getting nervous because of the lack of any feedback or progress on this issue. I realise it's holiday time in the USA, so I'll give it a few more days to hopefully get some feedback (better still: see progress). If that does not happen, I would like to go for a plan b:

- rename Chart 7.x-2.x Release to Chart 7.x-3.x Release
- rename Chart 7.x-1.2 Release (= this issue) to Chart 7.x-2.x Release

Probably something similar for D6.

That way there is no more need for the feedback that doesn't seem to appear, AND I comply with the original request to stick to 7.x-2.x

To anybody against my plan b: don't wait too long to let me know what's wrong with it. And for anybody who "likes" my plan b: some type of support would be appreciated.

Updating this issue as per #20.

26.323 (EUR fmt ...) sites using the chart module is the new record since last weekend ... I seem to remember that there was a time that the recommendation was to migrate from chart to some other module for charting, like charts ... Also because of some 2015-deadline ... There was a time that I thought that would indeed be the best to do (=go from chart to charts), I just didn't see that happen soon, for all sorts of reasons, especially because of the current status of #2374789: How to migrate from chart to charts?.

We are a few months later, I've been fairly silent in the chart issue queue, but I have not been sleeping (a lot) ... May I say "now that I have a lot of experience with both chart and charts", I think I actually have a solution (for now in my mind only ...):

1. to address the 2015-deadline (with minimal impact for the current chart sites, ideally only a chart release upgrade).
2. to have chart take advantage of various charts features (via software reuse, not by reinventing the wheel ...).
3. to make chart complimentary to charts (depending on your criteria you should go for either one).
4. to achieve my goal about charting with Drupal ... For those who don't know, or remember, visit #2368793: Chart 2.0.

Anybody interested in knowing about what I have in mind? Or contribute to it? For anybody interested in sponsoring (some) of the remaining work to be completed, please contact me.