45 APIs, file formats and protocols might be semanticly versioned independently from the implementation; |
45 APIs, file formats and protocols might be semanticly versioned independently from the implementation; |
46 in such case, there should be a table documenting which API/format/protocol version matches which implementation version. |
46 in such case, there should be a table documenting which API/format/protocol version matches which implementation version. |
47 </li> |
47 </li> |
48 </ul> |
48 </ul> |
49 |
49 |
50 <h2>Compatibilible with itself</h2> |
50 <h2>Compatible with itself</h2> |
51 <ul> |
51 <ul> |
52 <li>focus on backward compatibility</li> |
52 <li>Focus on backward compatibility. Newer version should work as a drop-in replacement.</li> |
53 <li>don't broke things</li> |
53 <li>Don't broke things – rather postpone the release date than deliver a faulty product.</li> |
54 <li>incompatible changes must be planned and announced in advance</li> |
54 <li>Don't remove features unless they are really obsolete, unused or unrepairably broken.</li> |
|
55 <li>Incompatible changes must be planned and announced in advance. <!--Major/minor/patch numbers must be increased according to the Semantic versioning.--></li> |
55 <li>upgrade scripts + upgrade documentation</li> |
56 <li>upgrade scripts + upgrade documentation</li> |
56 </ul> |
57 </ul> |
57 |
58 |
58 <h2>Compatibilible with others</h2> |
59 <h2>Compatible with others</h2> |
59 <ul> |
60 <ul> |
60 <li>use open standards (protocols, formats) if they exist</li> |
61 <li>use open standards (protocols, formats) if they exist</li> |
61 <li>define own open standards if needed |
62 <li>define own open standards if needed |
62 <ul> |
63 <ul> |
63 <li>also standards must be semantically versioned</li> |
64 <li>also standards must be semantically versioned</li> |