1
redheadedrod
Suggested module naming

I wanted to start a new thread to discuss a topic that need to be addressed by the community. We have had multiple issues in the past with modules being forked by developers that are not the original developer that retain the modules name and just bump up the version numbers.

I want to point out I am just a user at this stage but as a community we need to establish some rules to help developers and users keep things straight with new module. It is an open source community but the lack of current structure has allowed some modules to get posted that get confused as being a new version of a module when in fact it is a fork.

Anything decided should be included in the documentation about how to build modules so when developers come to xoops and either rework a module or build from scratch they see the information in the documentation. Might not be a bad idea to have a note included on the API website as well.

2
redheadedrod
Re: Suggested module naming

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?


3
irmtfan
Re: Suggested module naming
  • 2013/3/19 2:35

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


good discussion.
Just one thing is not clear.
some modules like news and newbb have a very long history so credits are too long and currently are not belong to any author.
I think we can consider them as community driven modules
IMO the most important issue in xoops is not conflicting end users by developing a same module by different developers.

The main issue is why some developers cannot work together on the same module as a team.


Login

Who's Online

160 user(s) are online (110 user(s) are browsing Support Forums)


Members: 0


Guests: 160


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Mar 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits