Rolling Release Application Structure

[ilkerkesen]

Veritabanını her sene sıfırlamamalıyız. Rolling release modele geçmeliyiz kısacası.

[celaleddin]

Just wondering, why did you close this issue?

[ilkerkesen]

I think in the short term, we don't have any practical solution, so currently there's no need for this issue.

[mertsalik]

Can i look for a solution or test sth. for help ? 👊

[ilkerkesen]

I think everybody is open to solutions. At least for the next year :)

So, we want to have just only one database. Currently, we backup and reset database after each year. The problems are the following,

• We need to add year field or something like that to project entries (easy)
• Score calculation procedure needs to differ from year to year (easy)
• Interfaces should be adaptive, since calculation process changes in every year, interfaces should adapt themselves (no idea currently, but it can be possible somehow).
• Scenario category is re-designed from scratch in every two years. I think separating scenario categories is the best solution we have. Hence, we need to add a new model for a new category and keep the previous ones.
• We need to handle that manager-project relation with this new additional year constraint.
• We need to port category administration from configuration files to interfaces. It should be handled elegantly also, that's essential :)

[mertsalik]

We can add a new 'event' module that will have some properties like

• location (organization takes place)
• time ( start, end, registeration etc.)
• etc.

So we can bind projects / orders and other date related models with this new table. And this module will be managed in only admin mode ? What are your thoughts on this subject? @ilkerkesen @celaleddin @alperkesen