Following is the proposed timeline for the D7 Port of Neologism, as requested at #837046: D7 Port of Neologism module

May 30 - June 5 (1 week) [DB Migration]
Neologism is currently running on D6. There are a lot of differences between the Evoc module in D6 and D7. Thus, we need to change the DB Schema of Neologism to match the D7 Version of Evoc.

June 6 - July 24 (7 weeks)[Porting Neologism to D7]
This is the major task of the project. This task has been further divided into sub-tasks as follows :
Week 1 : Port the menu system and vocabulary list to D7
Week 2 : Port the vocabulary overview page to D7
Week 3 : Port the RDF output to D7
Week 4 : Provide the feature of importing and loading vocabulary by using the evoc module
Week 5 : Port the vocabulary creation/edit form to D7
Week 6 : Port the class/property creation/edit forms to D7
Week 7 : Port content negotiation and caching to D7

July 25 - July 31 (1 week) [Documentation Migration/Upgrading and Migrating the code to Drupal Repository]
The tasks planned for this phase are as following :
Set up Drupal.org infrastructure for neologism module
Coordinate with documentation team to move existing documentation to drupal.org
Update documentation wherever needed
Notify existing users of the changes

August 1 - August 7 (1 week) [Test the module on existing Drupal sites]
We would need to evaluate how the Neologism module works if installed into existing D7 sites and identify any issues. Currently Neologism is built as an installation profile which installs an entire site that provides just a vocabulary editor. There might be some initialization which was previously done during the installation procedure which would now need to be done when the Neologism module is installed into existing sites. We need to make sure there are no issues faced when the module is installed or reinstalled into existing D7 sites.

Comments

Anonymous’s picture

Anonymous (not verified) commented

Week 3 and Week 7 will be made easier by work going on in #781972: Use RestWS for non-RDFa serializations and content negotiation in Drupal 7. You will want to watch that issue and review patches on it to ensure that the end result works in the context of what you're doing.

scor’s picture

scor commented

July 25 - July 31. Migrating the code to Drupal Repository

I'd say this should be the first thing to do. Maybe not migrate the 6.x code, but start off the 7.x code on the git repository right away (why learn 2 systems when you can just do with one?). You'll also hit less problems if you're d.o infrastructure from the beginning, as opposed to moving at the last minute and running into unforeseen problems then.

scor’s picture

scor commented

There are a lot of differences between the Evoc module in D6 and D7. Thus, we need to change the DB Schema of Neologism to match the D7 Version of Evoc.

Indeed, and since you will be using module out side the realm of Neologism whose schema might change, you might want to use their APIs instead. See #1151618: Data migration process from Drupal 6 to Drupal 7 for discussion on that topic.

scor’s picture

scor commented

Not sure if everyone has subscribed to the Neologism issue queue, so just in case you missed it: #1151794: Neologism as a feature.

cygri’s picture

cygri commented

July 25 - July 31. Migrating the code to Drupal Repository. I'd say this should be the first thing to do.

Yes. We should create a branch for D7 in the Neologism d.o git repository. Then the D7 version of the module should be built in this branch. We have two options:

a) start by putting a copy of the D6 code into the D7 branch, and step-by-step adapt that code to D7; or
b) start with a new empty module, and add features to it one by one, by copying and adapting whatever code is necessary to make a particular feature of the module work

To me it seems that b) is a better approach, because we'll always have a version that completely works with D7 (although it might not be doing much). I think that's better than having a huge mix of D6 code and D7 code in the same branch at the same time. But I might be wrong; would be interested in hearing experiences from those who have already migrated modules from one version to another ...

scor’s picture

scor commented

+1 for b) start with a blank slate, it will help to refactor and prevent any stale D6 code to creep in.

mayankkandpal’s picture

mayankkandpal commented

I would also prefer approach b) since :
It seems to be a cleaner approach and as Richard says, it always gives us a working D7 module.

Also, I believe that starting the module from scratch would provide me a better learning experience.

mayankkandpal’s picture

mayankkandpal commented

Another couple of things that might be helpful during the project:

1. Coder module (http://drupal.org/project/coder), as previously suggested by Stéphane in one of the emails

2. Simpletest testing framework (http://drupal.org/simpletest)

mayankkandpal’s picture

mayankkandpal commented
Status: Needs review » Active
Anonymous’s picture

Anonymous (not verified) commented
Version: 6.x-1.x-dev » 7.x-2.x-dev

Switching to 7.x branch