2
When a developer adopts an old module or decides to make modifications on their own they should be naming the new module something different to note the difference. Unless they have gotten permission from the original author to update the module directly they need to make sure the name is changed in some way.
Because of the past history of forked versions of modules being confused as being a newer version of a module I think a module shouldn't be accepted into the SVN unless the name is slightly different in some way. Before a developer is given commit rights to the SVN they should be made to understand this policy so there is no confusion. One would only then have their commit permission removed if they continually try to commit modules against this policy.
We have had both well meaning developers release updated modules that contain many bug fixes as well as bug ridden modules including "bleeding edge technology". Sometimes one is left wondering if the author of the "bleeding edge" module purposely left it bug ridden to promote being paid to fix the module leaving users confused on if a previously free module is no longer free.
So if there was an original module that lets say is called "download". Someone comes along and updates this module and builds many new features into it. This might become something along the line as wf-downloads. And someone else wants to build a download module that is very different. They would then perhaps call theirs tdm-download or something similar.
This becomes especially important with official or highly publicized modules such as those in the module packs. We continually have issues with the profile module and a developers often bug ridden version of a "newer module" being installed by users thinking it is the official module.
I personally think that we need to establish a policy to help keep the quality of xoops up and keep the support issues limited as much as we can when trying to support modules especially these highly visible modules.
With an established policy it will be easier for the module developers to be clear with their modules intentions as well as prevent future issues since it should be known.
Once this policy is established THEN we can do something like post an official 2.0 version of Profile and not accept any newer versions of it to the SVN unless the module name is changed to show it is a fork.
Comments?