Hello, Why I decide to fork a variant

[simkimsia]

Taken from the readme

Why fork?

In short:

1. I use this heavily for paid projects.
2. There are some gaps for the original version.
3. I want to be proactive in maintaining a variant for my own usage.

Specific Gaps

I (KimSia) uses the original django-ltree in a paid customer project.

That customer project uses Django 2.2.

In June 2022, I needed to run a docker exec -it <container_running django> python manage.py <some_command_that_does_not_need_database>.

That conflicts with check_database_backend_is_postgres.

More details in this PR.

Simultaneously, I noticed a separate PR in March 2022 about upgrading to 3.2. That PR is still not merged as of 2022-06-10 Friday.

I expect to upgrade this customer project to 3.2 Django in the near future as well.

Referencing Adam Johnson's Well Maintained Test for dependencies, question 11 and 12, I quote

11. Has there been a commit in the last year?

Maintainers tend to abandon packages rather than explicitly mark them as unmaintained. So the probability of future maintenance drops off the longer a project has not seen a commit.

We’d like to see at least one recent commit as a “sign of life”.

Any cutoff is arbitrary, but a year aligns with most programming languages’ annual release cadence.

12. Has there been a release in the last year?

A backlog of unreleased commits can also be a sign of inattention. Active maintainers may have permission to merge but not release, with the true “owner” of the project absent.

As of 10 June 2022, both answers are close to being no given it's been nearly 10 months since the most recent release and commit in August 2021.

I prefer using the upstream version, but in case it's going to be abandoned or unmaintained, I fork it and make it work for my use case.