Relates to: FEP-a4ed: The Fediverse Enhancement Proposal Process
So, suppose this happens 5 times. Do we now have 6 FEP’s where we have to choose different name than FEP-1b12: Group federation? How to name those? Add versions to the title? A FEP is stronger if its name refers to some consistent concept or feature of the protocol.
If we once more take XMPP as an example, for instance XEP-0060: Publish-Subscribe, the metadata has both a Status: Stable and a semantic Version: 1.26.0 (2023-09-07). I think adding versioning like this to the FEP is an improvement, esp. for evolving functionality that is mostly backwards-compatible.
The current process has replaces and replacedBy pointing to a different FEP document. I’d use that for cases where there’s big breaking changes, e.g. prefer some new authentication mechanism and the old one should be avoided.
1 Like
Definitely think a semantic version would be good.
Not sure about the Status: Stable thing. Usually that kind of thing is signaled by a 0.x.y version, as explained in the semantic versioning spec.
Yes, XEP has much more formality to the standardization process, with a council and voting and such. Status: Stable corresponds to reaching v1.0.0 of the spec. The process is:
+--> Retracted
|
|
+--> Deferred +--> Rejected
| | |
| | |
Experimental --+-> Proposed ----> Stable ---> Final
^ | | |
+----------------+ | |
+-----------+---> Deprecated
|
+--> Obsolete
After an XMPP Extension Protocol has been accepted for publication by the XMPP Council and before it is proposed for advancement to a status of Stable (or retracted or deferred), it shall have a status of Experimental. Publication as an Experimental XEP does not indicate approval of the protocol by the XMPP Council or the broader XMPP community.
Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Stable. While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch).
For Status: Final the following description is given:
A Standards Track XEP is in the Final state after it has been in the Stable state for at least six (6) months, has been implemented in at least two separate codebases, and has been voted forward on the standards track by the XMPP Council.
Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications.
See: XEP-0001: XMPP Extension Protocols
1 Like
I would name it Group federation (2025 edition).
Some FEP authors already use versions and keep changelogs. Example: https://codeberg.org/fediverse/fep/src/branch/main/fep/9fde/fep-9fde.md#fep-9fde-mechanism-for-servers-to-expose-supported-operations
I think this is a good practice. I am not opposed to adding a metadata field for tracking versions like that, but I am strongly opposed to adding new features to finalized proposals, because then “My software implements FEP-x1y2” statement loses meaning.