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.
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:
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.
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.
Wouldn’t it just become “My software implements FEP-x1y2 v1.2.3”? It’s quite common for all other software to state versions when talking about what features are supported and such. I don’t see why FEPs are different.
Versions are great. It would be fantastic to have them in the Fediverse.
However! The Fediverse currently has no protocol negotiation mechanism. That means in order to use FEP version information, you will need to
lookup what software you are talking to,
look up its version,
determine what version of a FEP it implements,
and react accordingly.
Frankly, I don’t think that would be a meaningful mechanism. Add to this that implementing a FEP or not is rather vague. There are few tests that need to be passed to see if a FEP is implemented correctly or not.
As I’d like to keep FEP simple. I think sticking with possible versions in the FEP name is enough for support. A more technical solution can be sought, if we get some version of protocol negotiation.
There’s a bit of an issue with the current naming. I observe that those deeply involved in particular FEP’s in their fediverse discussions start to refer to them only by their ID. They say something in toots like “Just stick to fep-1b12 and you’ll be fine”. No link to the FEP and no title of the FEP mentioned.
In other words, pure fedi-dev ‘insider talk’ and no hooks for other fedizens to glean the context of the toot and chime in. And when a link to a FEP markdown doc is dropped in a toot, it doesn’t generate an opengraph link preview that shows the title either.
TLDR People start to think in FEP ID’s and not in terms of protocol capabilities to support.
IMHO it would be better if FEP ID’s weren’t so prominent. They are not easy to remember, they are not intuitive, they are for machines not for people.
That’s a good point, but I don’t think that precludes us from adding a version to FEPs regardless. Any protocol negotiation added later can then take the version into account. I agree that the procedure you outline is not ideal, but not having versions doesn’t change it.
I mean if instead of having FEP-1a2b version 1.0.0 and FEP-1a2b version 1.1.0, we instead had FEP-1a2b and FEP-3c4d (where the latter is just an updated version of the former), you’d still need to do basically the same steps. With the versioning, you could at least use the semantic version to decide that something is still compatible, i.e. you support FEP-1a2b version 1.0.0 so therefore you should also be compatible with FEP-1a2b version 1.1.0. I think having versioning would greatly help when/if some negotiation procedure arrives some day.
Until we actually have some kind of generalized protocol negotiation, we’ll need FEPs to specify how they signal that the FEP is supported (i.e. each FEP need to specify how support is signaled to others, since there is no general mechanism to discover this). This is why I advocated for a particular addition to the type field here.
Perhaps this could be included as a reminder in the FEP template? At least until we have some kind of protocol negotiation in place. Then at least new FEPs are more likely to include some kind of explicit protocol discovery mechanism.
FEPs are similar to standards. When the work is finished, they become foundations of complex technical systems and independent software projects rely on them to reach agreements. There is an expectation of unchangeability.
Other standard processes have similar rules. RFCs can’t be changed once they are finished: IETF | RFCs. XEP, like FEP, allows only small modifications: XEP-0001: XMPP Extension Protocols. W3C recommendations can be versioned, but a new version typically requires a multi-years process involving industry representatives.