Proposal type
Other
Affected scope (files/folders/chains)
https://github.com/Chain-Love/chain-love/wiki/Style-Guide
Motivation / problem statement
The Style Guide says to avoid tools that are:
deprecated,
archived,
or not updated for more than one year.
But there is an important unresolved question:
What happens when an offer already exists in Chain.Love and subsequently becomes inactive?
For example:
A new offer has recent activity when added.
Two years later, the repository has had no meaningful updates for 20 months.
Is it automatically invalid?
Should it be removed?
Should it remain as historical data?
Should it be marked legacy?
Should its listing be removed?
Does the >1-year rule apply only to new additions, or also to existing offers?
Proposed lifecycle states
This DBIP is proposing something along these lines:
Active
Current development/maintenance is evident.
↓
Inactive
No meaningful update for >1 year but the project remains available and not explicitly deprecated.
↓
Deprecated
Official documentation/repository explicitly says the project is deprecated or superseded.
↓
Archived
Repository/project is explicitly archived or no longer maintained.
↓
Removed / Historical
Define whether and when the record should disappear from the active database.
Important distinction
No release for >1 year is different
from
No meaningful repository activity for >1 year
and from
Officially deprecated
and from
Archived.
These are not necessarily equivalent.
This would solve some of the ambiguities in the database validation.
It would also help with projects like:
legacy SDKs;
old developer tools;
abandoned libraries;
superseded protocol tooling;
projects placed into maintenance/standby mode.
Detailed proposal
If proposing a new/changed category (table):
- Category name:
- Purpose and scope:
- Primary use cases:
- Example entities/providers to include:
- Does this category applies to specific chains? If so, list them:
- Required columns (list):
- Optional columns (list):
If proposing column change(s):
- Category/table (rpc | wallet | explorer | indexing | bridge | analytic | devTool | oracle):
- Column name:
- Change type (add | remove | modify):
- New/updated definition:
- Value type and allowed values (string | number | boolean | JSON array | JSON object | NULL | enum:):
- Examples (concise):
- Notes (constraints, normalization guidance (check wiki for references)):
Contact (optional)
No response
Rewards address (optional)
0xbebb8c6309b58218b62138ed88669658ebe4804a ERC20
Proposal type
Other
Affected scope (files/folders/chains)
https://github.com/Chain-Love/chain-love/wiki/Style-Guide
Motivation / problem statement
The Style Guide says to avoid tools that are:
deprecated,
archived,
or not updated for more than one year.
But there is an important unresolved question:
What happens when an offer already exists in Chain.Love and subsequently becomes inactive?
For example:
A new offer has recent activity when added.
Two years later, the repository has had no meaningful updates for 20 months.
Is it automatically invalid?
Should it be removed?
Should it remain as historical data?
Should it be marked legacy?
Should its listing be removed?
Does the >1-year rule apply only to new additions, or also to existing offers?
Proposed lifecycle states
This DBIP is proposing something along these lines:
Active
Current development/maintenance is evident.
↓
Inactive
No meaningful update for >1 year but the project remains available and not explicitly deprecated.
↓
Deprecated
Official documentation/repository explicitly says the project is deprecated or superseded.
↓
Archived
Repository/project is explicitly archived or no longer maintained.
↓
Removed / Historical
Define whether and when the record should disappear from the active database.
Important distinction
No release for >1 year is different
from
No meaningful repository activity for >1 year
and from
Officially deprecated
and from
Archived.
These are not necessarily equivalent.
This would solve some of the ambiguities in the database validation.
It would also help with projects like:
legacy SDKs;
old developer tools;
abandoned libraries;
superseded protocol tooling;
projects placed into maintenance/standby mode.
Detailed proposal
If proposing a new/changed category (table):
If proposing column change(s):
Contact (optional)
No response
Rewards address (optional)
0xbebb8c6309b58218b62138ed88669658ebe4804a ERC20