Release cycle nl NL

Release-cyclus

ASF gebruikt versie C# met 4 getallen, geschreven als A.B.C.D. De gegeven versie is altijd bevroren en wijst naar een vaste broncode waaruit deze is gebouwd (gebundeld samen met de release). We zijn niet van plan om een vooraf gepubliceerde versie te verwijderen, zolang onze hostingprovider (GitHub) prima blijft met het behoud ervan voor onbepaalde toekomst. zodat je veilig naar elk van hen terug kunt gaan zonder dat je zelf hoeft te kopiëren.

In het algemeen in termen van ASF-versie, We doen ons best om semver versie van te volgen. INOR.PATCH op de drie minst belangrijke getallen - B.C.D. Deze drie getallen houden rechtstreeks verband met ASF's code. Het belangrijkste A nummer geeft wijzigingen aan met een bereik dat verder gaat dan de ASF codebase zelf, meestal direct van invloed op de basis van het programma.

ASF als een project streeft ernaar om min of meer één feature release per maandte hebben, aangegeven door een bump van C nummer. Om een dergelijke release mogelijk te maken, hebben we kleinere pre-releases gewijd aan geavanceerde gebruikers, die dienen als kleinere mijlpalen bij veranderingen die op de noodzakelijke basis worden vrijgegeven, wanneer er genoeg veranderingen zullen zijn sinds de laatste pre-release om op te focussen. Uiteindelijk wanneer een definitieve pre-release stabiel en volwassen genoeg zal zijn zonder bekende kritische regressies die gecorrigeerd moeten worden in vergelijking met eerdere stabiele release, het zal worden gepromoveerd tot de nieuwe stabiele release, terwijl er tegelijkertijd een nieuwe maandelijkse cyclus wordt geopend voor de volgende.

Terwijl we ons best doen om ervoor te zorgen dat zelfs onze pre-releases relatief stabiel zijn. het dient te worden opgemerkt dat pre-releases zorgvuldig moeten worden geëvalueerd wanneer ze in elke productieomgeving worden uitgevoerd. Pre-releases might have critical bugs and otherwise broken functionality, which is exactly why we're releasing them to begin with - so we can avoid all of that mess in our stable builds and offer reliable software. Als u niet bereid bent om een verhoogd risico te accepteren dat voortkomt uit het gebruik van potentieel onstabiele software, vermijd alstublieft onze pre-release versies te gebruiken en houd vast aan onze nieuwste stabiele build in plaats daarvan. die beter geschikt is voor de meeste gebruikers.

Afhankelijk van het aantal veranderingen in de cyclus, zal er meestal één C versie bump zijn (van de vorige stabiel), en D bumps voor elke pre-release op basis van de vereiste basis. Wanneer u echter veranderingen introduceert met een veel grotere reikwijdte, vooral brekende verandering, de cyclus kan starten vanaf (of wisselen in het midden om) B of zelfs A bump - deze schakelaar geeft aan dat de huidige releasecyclus in potentie instabieler is dan normaal, en moet zorgvuldig worden getoetst. Hou in gedachten dat wijzigingen in de halve versie alleen betrekking hebben op eerder vrijgegeven stabiele versie, we houden versiebeheer niet bij door vooraf releases in een cyclus zelf, wat betekent dat versie 1. .1.2 heeft mogelijk een nieuwe functie 1.0.1. heeft niet gehad, zolang de eerder gemarkeerde stabiele versie van 1.0.X familie is. Ook kunnen er grote veranderingen optreden, zelfs in twee van tevoren vrijgegeven uit dezelfde cyclus, wat vooral waar is wanneer we nog beslissen over de definitieve vorm van nieuw ingevoerde functionaliteit of iets dergelijks.

Versie bump	Semver	Voorbeeld van wijzigingen
A		Grote .NET runtime verandert, de basis verandert, veranderingen inbreken, veranderingen die verder gaan dan ASF's codebase, dingen die jouw kat misschien eten
B	Groot	Kleine .NET runtime verandert, veranderingen in ASF codebase, grote code bewerkingen die verder gaan dan kleine classificatie
C	Klein	Nieuwe maandelijkse cyclus, meestal introduceren nieuwe functies, commando's, configuratie-eigenschappen of andere wijzigingen die de bestaande instellingen niet breken
D	Patch	Nieuwe pre-releases die deel uitmaken van de bestaande cyclus (aangegeven door een groter aantal), kritieke bugfixes op bestaande stabiele releases die geen codewijzigingen introduceren verder dan nodig

Houd er rekening mee dat nieuwe functies en wijzigingen ongedocumenteerd kunnen zijn (bijv. op de wiki) tot enige tijd later, omdat documentatie meestal wordt geschreven zodra de slotcode van de gegeven functie klaar is (om ons tijd te besparen bij het herschrijven van documentatie, telkens wanneer we besluiten de functie aan te passen waar we momenteel mee bezig zijn). Vanwege het feit dat vooraf releases een werkcode kunnen bevatten die nog geen definitieve vorm heeft. documentatie kan in een later stadium van de ontwikkeling aankomen. Hetzelfde geldt voor de algemene changelog die mogelijk niet beschikbaar is voor bepaalde pre-release tot een later tijdstip. Als je daarom besluit om pre-releases te gebruiken, moet je voorbereid zijn om binnen ASF commits te kijken. Of course, lack of documentation applies only to pre-releases - each stable version must always have a complete changelog and documentation on the wiki the moment it's being released.

De precieze changelog die de ene versie met de andere vergelijkt, is altijd beschikbaar op GitHub - door commits en code wijzigingen. Vrijgeven we alleen wijzigingen te documenteren die we belangrijk vinden tussen de laatste stabiele en de huidige release. Zulke korte wijzigingen zijn nooit volledig. dus als je elke verandering wilt zien die gebeurde tussen de ene versie en de andere (zoals onze dependencies upgrades) - gebruik dan GitHub vergelijking daarvoor.

ASF-project wordt gevoed door onze continue integratieproces. Elke build moet reproduceerbaar zijn dus mag het geen probleem zijn om de gegeven versie te pakken en jezelf te compileren met hetzelfde resultaat als het resultaat dat beschikbaar is via onze vooraf gecompileerde binaries. We vermijden meestal zelf om releases te compileren, zolang de systemen operationeel zijn, de vrijgekomen binaries rechtstreeks uit ons CI-proces komen.