Archive older migrations by year

Open
#12,447 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
php
Domain
database

Research direction

Start by reviewing Submitty/migration/migrator/migrations/course and the related issues #2515 and #12446. Compare the proposed year-based organization, upgrade-gap restriction, and release-tag approach with the existing migration process. Done means the project has selected and documented a concrete approach with an agreed scope and validation plan.

Written by the indexing model from the issue text.

Description

enhancement / feature request Migrator question / design / discussion needed

What problem are you trying to solve with Submitty
We currently have ~550 migration files in
Submitty/migration/migrator/migrations/course
This is a bit overwhelming.
Also, if someone is update a system that is very-out-of-date, it is possible that the migrator will not successfully complete the running of a set of migrations over many months (or even years).

See: Chronological interleaving of system/master/course migrations
https://github.com/Submitty/Submitty/issues/2515

And see: Verify Migration File datestamp using a Github Action test
https://github.com/Submitty/Submitty/issues/12446

NOTE: It is handy to have samples of migration files for new developers to learn from. So we don't want to discard all the old files necessary.

Describe the way you'd like to solve this problem

Proposed Ideas for discussion:

  1. Let's organize migrations for system/master/course migrations into an additional directory hierarchy level with subfolders by year.

  2. Let's revise the migration system to force the sysadmin to take smaller steps when upgrading a system. If the oldest unapplied migration is more than 6 months old, the migrator should fail and instruct the sysadmin to first update the system to an intermediate release so that the gap in migrations is < 6 months. (Is "6 months" a good threshold? Could be something else.)

  3. Alternatively / Additionally, we could compare the repo release tags and not allow a jump of more than 6 months. E.g., v25.09.00 -> v26.02.00 ALLOWED but v.25.03.00 -> v26.02.00 NOT ALLOWED. Note that the Submitty/Submitty repository does usually have at least one release per month, but the other helper repositories sometimes have periods > 6 months with no release. So maybe we need to check and see if there are other valid intermediate releases in between before failing.

Dominant language
PHP
Stars
793
Forks
1.1k
Avg merge
2d 16h
Merged PRs (30d)
78

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Submitty/Submitty

All issues in Submitty/Submitty

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.