Versies

Versiestrategie

Stabiliteit zorgt ervoor dat de micro-services, API's, tools en geleerde praktijken niet onverwacht verouderd raken.

Dit document bevat de praktijken die worden gevolgd om u een taxonomie te bieden, in evenwicht met stabiliteit, zodat toekomstige veranderingen altijd op een voorspelbare manier worden geïntroduceerd.

DDB volgt Semantic Versioning 2.0.0 (opens new window) . DDB -versienummers hebben drie delen: major.minor.patch. Het versienummer wordt verhoogd op basis van het veranderingsniveau dat in de release is opgenomen.

• Belangrijke releases bevatten belangrijke nieuwe functies, maar er wordt tijdens de update enkele, maar minimale hulp bij de ontwikkelaar verwacht. Bij het bijwerken van een nieuwe grote release moet u mogelijk updatescripts, refactorcode uitvoeren, extra tests uitvoeren en nieuwe API's leren.
• Kleine releases bevatten belangrijke nieuwe functies. Kleine releases zijn volledig achterwaarts compatibel; Tijdens de update wordt geen hulp bij de ontwikkelaar verwacht, maar u kunt optioneel uw apps en bibliotheken aanpassen om nieuwe API's, functies en mogelijkheden te gebruiken die in de release zijn toegevoegd.
• Patch -releases zijn laag risico, bevatten bugfixes en kleine nieuwe functies. Tijdens de update wordt geen hulp van ontwikkelaars verwacht.

Release schema

U kunt de Huidige team voortgang (opens new window) Voor een meer gedetailleerd overzicht.

⚠️ Vrijwaring : We werken in een dynamische omgeving en dingen kunnen worden gewijzigd. De verstrekte informatie is bedoeld om de algemene raamwerkrichting te schetsen. Het is alleen bedoeld voor informatieve doeleinden. We kunnen besluiten om op elk gewenst moment nieuwe items toe te voegen/verwijderen, afhankelijk van onze mogelijkheid om te leveren terwijl we aan onze kwaliteitsnormen voldoen. De ontwikkeling, releases en timing van eventuele functies of functionaliteit van DDB blijft naar eigen goeddunken van het DDB -team. De road-map vertegenwoordigt geen verplichting, verplichting of belofte om op elk moment te leveren.

Afschrijvingspraktijken

Soms zijn "het breken van veranderingen", zoals het verwijderen van ondersteuning voor geselecteerde API's en functies, nodig. Om deze overgangen zo eenvoudig mogelijk te maken:

• Het aantal breukwijzigingen wordt geminimaliseerd en indien mogelijk migratietools.
• Het hieronder beschreven afschrijvingsbeleid wordt gevolgd, zodat u tijd hebt om uw apps bij te werken naar de nieuwste API's en best practices.
• Meldingen worden gepubliceerd binnen de toepassing en Yammer -groepen om de bijbehorende tijdlijn te identificeren.

Afschrijvingsbeleid

• Verouderde functies worden aangekondigd in de Changelog en indien mogelijk met waarschuwingen tijdens runtime.
• Wanneer een afschrijving wordt aangekondigd, wordt het aanbevolen updatepad verstrekt.
• Bestaande gebruik van een stabiele API tijdens de afschrijvingsperiode wordt ondersteund, zodat uw code in die periode blijft werken.