Create Matomo module; leave Piwik to be deprecated #146
Conversation
|
Not sure what to do about the failing tests. They seem unrelated to this PR. |
|
Indeed, those errors are unrelated. I'm merging your changes. Thanks for the contribution! |
|
Super. Thank you all for django-analytical. |
|
Yes, the issues are unrelated, but as the PRs are configured it may be best to fix them on a separate branch first and rebase this PR on the fixed |
|
@bittner : that would be great. |
|
True, I'll fix master. |
|
@jcassee @sckarlin What I'm actually worried about in this PR is that we're unnecessarily duplicating code.
The point is, when we're removing the Piwik code we should have prepared everything. It should be obvious and easy to understand which parts to remove (and those parts should be really small -- to avoid human error!). Does that sound okay? |
|
My thought is that the piwik module should stick around for a bit longer (6-12 months?) for those folks who may still be using a clone of the old Piwik code on their own servers which relies on the old names. |
|
Sure! It can stick around for even longer! It probably will. And that's why we should prepare the phase-out. That's what I say. |
|
OK, so then both the Piwik and the Matomo modules need to co-exist with the Piwik module frozen as-is (using old interface names) and the Matomo module free to move forward with new features (such as proposed in #142). Correct? |
|
No, the total opposite! I don't think it's worth conserving the old Piwik integration code. That should move forward just as Piwik/Matomo moves forward. If there's anything serious to implement in a backward-compatible fashion that should go into the new module. The Piwik module should become just a hollow facade, a proxy to the new Matomo integration. Remember: It's really all about renaming. |
|
Hmm, I believe this is the right way. If that proves to break the integration with an older Piwik instance developers can still stick to the current or an older django-analytical version, can't they? Maybe I'm wrong. Let's discuss. |
|
This seems a little more complicated than necessary to me. Perhaps I'm not understanding. If we were to have only one module named matomo going forward, are you suggesting we put conditionals in the python code so that this module works with Piwik servers, if needed? For example, the javascript snippet used for the last Piwik-branded version has since diverged from the current Matomo-branded version. I do agree that having a fair amount of duplicate code between the Piwik module and the Matomo module is not ideal; however, if we consider the Piwik module "frozen" then when the time comes to remove it completely, it'll be much easier. By "frozen," I'm suggesting there would be no back-porting of new features for Matomo that theoretically could work with Piwik. |
|
Good point about using an older version of django-analytical for older Piwik support. |
|
Alright, let's leave the Piwik module as it is. Sorry for the noise. You can now rebase your branch onto the new |
|
You should also add yourself to the AUTHORS.rst file and update the date information in the LICENSE.txt file. |
|
All done. Thanks for your guidance. Good discussion. |
With the rebranding of Piwik to Matomo, this commit: * copies the piwik module to matomo and rebrands * notes that the piwik module is deprecated * updates the javascript to the current Matomo version Implements jazzband#132
|
I performed an updated rebase. Let me know if there are any issues. |
|
Thanks @sckarlin! |
|
Should we release a version 2.6.0 now, @jcassee? |
Absolutely. Will you or shall I? |
|
I think we both will have to be involved! 😏 As it must go through a PR. Can you create the PR? I'm interested whether pushing a tag to the master branch will work afterwards. 😬 |
|
@bittner I think according to https://jazzband.co/about/releases we can just push a release commit? |
|
Try and we'll see what happens. |
With the rebranding of Piwik to Matomo, this commit:
Fixes #132