Would be great to support the D6 version while Core is still currently supported. Looks like there are 3,662 D6 users as of this week.
I know that the energy of the developers isn't with the D6 release, but we really have to look at how to maintain these projects for the lifespan of the two officially supported releases of Core.
I don't want to put more pressure on the developers, but there are a lot of user of this module who will be getting "Project not supported: This project is no longer supported, and is no longer available for download. Disabling everything included by this project is strongly recommended!" messages on their Available updates page.
Maybe attempts like #2138397: Highlight Flattr, Paypal or Whatever Opportunities on Issue Pages or #2177459: Highlight Supporting Organizations in the Issue Queue could help add incentives to see that this code is still supported.
But it will probably be another year till that list of D6 users drops to under 1000. What are the best practices with dealing with older releases?
Comments
Comment #1
fonant commentedAgreed.
If the 6.x version isn't being supported, but is still OK to use, please could you re-publish it as a non-recommended version?
Just so I don't have to keep ignoring the "Project not supported: This project is no longer supported, and is no longer available for download. Disabling everything included by this project is strongly recommended!" message.
Comment #2
deekarma commented+1 - Atrium time tracker depends on views calcs and so I cannot disable it.
I would be really grateful if you could re-publish to avoid me having to ignore message.
Comment #3
wylbur commentedComment #4
mgiffordThanks @wylbur - yikes..
Comment #5
benkewell commented+1 for re-publish it as a non-recommended version
It forces my site keep displaying the "Project not supported" error and is very annoying.
Putting it into non-recommended version should be enough to keep people from using it in new projects.
Comment #6
grey_ commentedDropping support for a fully working project doesn't make sense. I mean, if it was broken and the maintainer actually had to do work on it in order to maintain it then so be it. But doing it like this is simply not nice.
Any comments?
Comment #7
grey_ commentedComment #8
benkewell commentedtotally agree to grey_
Putting it into non-recommended and then stop all developments on 6.x except security fixes should be enough
Comment #9
mgiffordI posted an idea about evaluating best practices for module maintenance that touches on this point #2186377: Highlight projects that follow Best Practices
It still needs considerable work.
Comment #10
Shai commented+1 for keeping D6 version a published non-recommended project.
Comment #11
panvera commented+1 for keeping D6 version a published non-recommended project.
Comment #12
mgiffordMaybe we need a new role for D6 maintainer. #2203331: Differentiation of the Maintainer Role
Might even be able to have a different incentive structure for legacy issues.
Comment #13
damienmckenna+1 for leaving the D6 branch & releases available, if unsupported.
Comment #14
mgifford@DamienMcKenna would love your 2c on https://drupal.org/node/2212549
I just drafted a best practice guide on dealing with legacy d6 code. It needs work.
Comment #15
NiklasBr commentedCan I pledge a few € or $ to persuade the maintainer(s) to at the very least remove the message "Project not supported: This project is no longer supported, and is no longer available for download. Disabling everything included by this project is strongly recommended!" until D8 is released?
Comment #16
deekarma commentedI would also pledge.
Comment #17
mgiffordI'm on Gittip. I'd pledge to maintain it via Gittip if someone stood up to maintain it. Not sure how it would amount to, but.... Who else is on here:
https://www.gittip.com/for/drupal/
Comment #18
liquidcms commentedsomewhat off topic; but wouldn't it be nice if the update module had a method to ignore certain modules? I mean this is really what most people are asking for here isn't it - more so than maintaining an old release of a module which works just fine?
it is up to the maintainer to not want to support an old version of a module and since having it listed on the project page means you can still post issues to a rel; not really any other way to do this. but pretty annoying for the update module to be all or nothing... "sorry, if you want to know about security updates then i will annoy the hell out of you forever if someone decides to stop maintaining a module."
and yes, i get that maybe this is dangerous.. what if someone "ignores" a module by mistake.. omg.. such a huge security violation! so how about a weekly or monthly reset on the ignores? security isn't the be all that people think on d.org... it could be months or never before the d.org security team finds a security hole in a module; which typically are not critical.
Comment #19
mgiffordWell, if there is a D6 version that works just fine, how do we know when there is a security release discovered next week?
By just having everyone ignore it (like we used to be able to do with the Update module back in the day) you just would not get those notices.
I think it's a better practice to keep it up on d.o but to mark the development state of D6 to make it clear that only security issues will be addressed.
Comment #20
fonant commentedThere is a module for ignoring module updates: https://drupal.org/project/update_advanced
Comment #21
liquidcms commentedMike, even security fixes take developer's time. So i guess you would always need a maintainer (which i get is part of this thread); but you wont always get that for every module (like i guess this one doesnt have yet).
But yes, if not listed as supported i guess project misses the "free" security team analysis. Thats open source.
@fonant - thanks for the module tip; will check it out.
Comment #22
mgiffordHey Peter, "even security fixes take developer's time" - totally. But if the D6 version were open and a security release was found an alert could go out at that time that could be either tell people that they should disable this module as it is no longer secure or tell them how them how to secure it.
If it's a big enough issue someone would write a patch to address it and that person could be a maintainer of the project.
When I opened this issue there were 3,663 sites which reported using the D6 version of this module. Now there are 3,361. It might drop down to under 1000 by the end of the year, but that will all be because of folks moving because of Drupal 8's release.
Comment #23
VinceW commentedPersonaly I would like to see a reaction from the maintainer(s) of this module why the D6 version was dropped.
Comment #24
NiklasBr commentedMeanwhile… Does anyone know any good ways to silence the non-support notification from this module?
Comment #25
mgiffordCheck out comment #20 above.
Comment #26
wildlife commentedI want to upgrade my sites to get off Drupal 6 but am unable to because the upgrade process seems virtually impossible for sites with complex functionality in a way where our data is preserved. I do not understand pulling support for Drupal 6 in ways such as this when there is seemingly no way to get off Drupal 6 without a complete site rebuild. This mindset of forcing people off Drupal 6 by ending support is putting a lot of us in a seriously bad position.
Comment #27
danny englanderFrom the maintainer of this module in several closed / won't fix D6 issues:
e.g.
https://www.drupal.org/node/1210038#comment-8486337
https://www.drupal.org/node/1363650#comment-8486353
https://www.drupal.org/node/1215582#comment-8486343
etc...
... but no reason ever given.
Comment #28
mgiffordThe implied reason is usually, "... we no longer have time or interest to maintain this code base which we no longer use."
Most developers are more keen on putting time into the Drupal 8 release than fixing/testing bugs in a version they stopped using years ago.
Still, there is room for the Drupal Community to appoint legacy maintainers for the older D6 branches. Soon that will be the D7 branches mind you.
Comment #29
rsvelko commented- Installed 6.x-1.x-dev downloading from the releases list. Still it did not do the job as expected... dont know why.
So I had to do call this function in a view header footer:
( feel free to adapt and debug via print_r() )
Comment #30
mgifford@rsvelko - that's off topic.
Comment #31
Pierre.Vriens commented+1 for keeping D6 version a published non-recommended project.
FYI: I'm the (new) maintainer of the chart module, and despite that this module is commonly perceived as "nearly end of live" (because of Google's deadline imposed), I'm working on getting it in good shape again soon.
The D6-version is used in +5K sites today ... still. One of its submodules of it (in the D6-version) depends on this module also. Which is why I'd rather want to say something like 5.000 * 50% = + 2.500 (instead of just +1) ... So if the D6 version of 'this' module would become published somehow again, it would help me a lot also (i.e. I wouldn't have to spend time on coming up with an alternative for this unsupported dependency).
PS: Please don't challenge me to become the D6 (only) maintainer of this project ... Before anybody wants to consider doing so, checkout #2368793-29: Chart 2.0.
Comment #32
Pierre.Vriens commentedUpdate about my prior #31 .. I just discovered that the D6 version of charts (which is not all the same module as chart ...) ALSO depends on the views_calc module. Be it that it is only a "weak module dependency", as you can see around here. Guess what: I am also the maintainer of charts these days.
The D6 version of charts is still used in nearly 600 sites today, while the D6 version of Views Calc is used today in 2.327 (EUR fmt!) sites. By considering the number of D6 sites using either chart or charts, I believe that "nearly ALL" sites using the D6 version of Views Calc, or also using either chart or charts. If there is anybody following this issue who does not use either chart or charts, please let us know about it.
Because of this new discovery, I would like to rephrase my PS in my #31: "Would you consider me to become the D6 (only) maintainer of this project?" ... Even if it was only to prevent me from "cloning" what is needed from this module into some new submodule related to chart and/or charts (which I'm considering adding in module csvchart, for which I'm about to release a D5-upgrade also).
Another option (which I'm not sure if it is possible), is to split the D6 and D7 version of the Views Calc project (and its D6 related issue queue). Or moving (instead of splitting) it to the csvchart module. Anybody familiar with what is possible to achieve such split or move?
Comment #33
Pierre.Vriens commentedWhat could be a possible explanation of the recent increase in the usage statistics of the D6 version of this module? Which as of today is still not showing up on the project page.
A hidden release that until recently was (still) used in about 50% of the D7 users, has now evolved in "about 200% of the D7 users" ... I don't understand ...
Comment #34
dddave commentedI've contacted Karen about this. If there is no response within a week please ping this issue again.
Comment #35
Pierre.Vriens commented@dddave: any news from your side? I haven't seen/heard anything, except my reminder in my calendar today (related to your #34) ... Suggestions about how to move forward now? FYI: my offer (in red) in #32 still stands. Maybe I should add to that "for as long as D6-core continues to be supported" (and slightly adapt the title of this issue also)?
PS: I like the "legacy maintainer" title from @mgifford).
Comment #36
dddave commentedI've not heard back from Karen. Therefore I've made Pierre.Vriens co-maintainer to deal with the D6 support.
Comment #37
Pierre.Vriens commentedThank you David! Guess what kind of update I just applied to the supported releases, right ... 6.x-1.3 is marked supported again (+ related dev snapshot ofcourse)! With that, I hope the over 8K D6 sites are "happy" again.
What I'm not sure about yet: what to do with the 6.x-3.x-dev version (used in 139 sites)? Anybody out there who can help me understand/decide please?
To all participants in this issue: thank you for your patience. I may need some time to come up to speed, any help, like pointers to existing docu, would be greatly appreciated ... same for docu contributions ... Where do we start?
PS to Karen (if she ever finds this comment): just trying to help, OK?
Comment #38
Pierre.Vriens commentedComment #39
magnus commentedThanks a lot for supporting this module again!
Comment #40
greenreaperSpeaking as the owner of one of those sites, it would be nice to have a 6.x-1.4, even if it was just the -dev version repackaged (though I suspect there are a few fixes that have been suggested since the last release of -dev). The reason we're on -dev is that -1.3 was so old, even then, and the -dev version was clearly larger.
Also, the -dev version is still showing up as "Not Supported" on our Available Updates panel, even though the date is the same as the last available date (2013-Oct-18).
Comment #41
Pierre.Vriens commented@GreenReaper: thanks for the feedback. I agree with you on such 6.x-1.4 (= repackaged -dev version, etc). Give me a little time to see what I can do for that.
Also thanks for the "still showing ..." hint (I didn't know, or I wasn't sure about that yet). Not 100% sure if I now "solved" that "still showing", but I just applied a modification like so (all 6.x related, and only 6.x, that "my" territory, remember?):
Please let me know "how close I am" with these changes (i.e. if there is anything "still showing" that should no longer be like so, ok?
Comment #42
greenreaperI'm still getting this after a manual refresh:
I don't know if there is some kind of caching on the Drupal side, though. I can check again later
My views_calc.info file is: