Release cycle no NO

Utgivningssyklus

ASF bruker felles C# versjonering med 4 nummer, skrevet som A.B.C.D. Angitt versjon er alltid frosset, peker til en fast kildekode den ble laget av (samlet sammen med utslippet). Vi har ikke planer om å fjerne noen tidligere publisert versjon, så lenge vår vertsleverandør (GitHub) holder seg fint med å bevare dem for ubestemt fremtid. så du trygt kan tilbakeføre til noen av dem uten behov for å ta selvkopier.

Generelt sett når det gjelder ASF-versjonering, Vi gjør det best å følge semver versjon av MAJOR. INOR.PATCH på de 3 minst signifikante tallene - B.C.D. Disse tre tallene er direkte relatert til ASFs kode. Den mest betydelige A nummer angir endringer med omfang som går ut over ASF-kodebase selv, vanligvis direkte innvirkning på fundamentet til programmet.

ASF som et prosjekt sikter på å ha mer eller mindre versjon per månedangitt med en kul av C -nummer. For å gjøre dette mulig har vi mindre forhåndslansering dedikert til avanserte brukere, som fungerer som mindre milepæler om endringer som kan frigjøres ved behov, når det vil være nok av endringene siden siste utgivelse skal fokusere på. Eventuelt, når en endelig forhåndsutløsning bestemmes å være stabil og moden nok til ingen kjente kritiske regresjoner som bør korrigeres i forhold til tidligere stabil frigivelse. vil bli fremmet til den nye stabile utgivelsen, samtidig som du åpner en ny månedlig syklus for den neste.

Samtidig gjør vi det vårt for at selv for-utgivelser kan bli relativt stabile, det bør bemerkes at forhåndsutslipp bør evalueres nøye når de kjører i produksjonsmiljø. Forhåndsutgivelser kan ha kritiske bugs og annen ødelagt funksjonalitet. – derfor slipper vi å begynne med - slik at vi unngår all denne tvilen i stabile bygg og tilbyr pålitelig programvare. Hvis du ikke er villig til å godta økt risiko som kommer fra ved hjelp av potensielt ustabil programvare, unngå å bruke våre versjoner før utgivelse og hold deg på vår nyeste stabile versjon i stedet, hvilket er mer hensiktsmessig for de fleste brukere.

Avhengig av mengden endringer i syklusen vil det vanligvis være en enkel C versjon kump (fra tidligere stabile), og D - pumper for hver forløslate ved behov. Imidlertid når det innføres endringer med langt større omfang, særlig brytende endringer. syklusen kan starte fra (eller gå i midtre til) B eller til og med A kump – en slik bryter indikerer at gjeldende frigjøringssyklus har et potensial til å være mer ustabil enn vanlig, og bør prøves med forsiktighet. Keep in mind that semver changes we're making relate only to previously released stable version, we do not track versioning across pre-releases in a cycle themselves, which means that version 1.0.1.2 might have a new feature that 1.0.1.1 didn't have, as long as the previously marked stable release is from 1.0.0.X family. På samme måte kan det også forekomme store brytningsendringer selv på tvers av to forhåndsutslipp fra samme syklus, som er spesielt sant når vi fremdeles bestemmer den endelige formen for nylig introdusert funksjonalitet eller lignende.

Versjon bump	Semver	Eksempel på endringer
A		Alvorlige .NET runtime endringer, fundament endringer, brytende endringer som er utenfor ASFs kodebase, ting som kan spise katten din.
B	Stor	Mindre endringer i driftstid, brytende endringer i ASF-kodebase, viktige kodeendringer som går utover mindre klasse
K	Mindre	Nye månedlige sykluser som vanligvis introduserer ny funksjonalitet, kommandoer, konfigurasjonsegenskaper eller andre endringer som ikke bryter de eksisterende oppsettene
V	Oppdatering	Nye frigivelser som er en del av eksisterende syklus (indikert et større antall), kritiske feilrettinger til eksisterende stabile utgivelser som ikke krever kodeendringer utover det som er nødvendig

Vær oppmerksom på at nylig innførte funksjoner og endringer kan udokumenteres (f.eks. på wiki) til en gang senere, Siden dokumentasjonen vanligvis skrives én gang endelig kode for gitt funksjon er klar (for å spare oss tid på å skrive dokumentasjon, hver gang vi beslutter å endre funksjonen vi jobber på). Fordi forhåndslansering kan inneholde arbeidskrevende kode som ikke har sluttskjema ennå, dokumentasjon kan komme fram til senere stadier av utviklingen. Samme ting gjelder for generell endringslogg som kan være utilgjengelig for gitt forhåndslansering til en tid senere. Hvis du bestemmer deg for å bruke forhånds-utgivelser, så vær forberedt for å lete inne ASF begår fra tid til annen. Selvsagt Manglende dokumentasjon gjelder bare på forhåndslanseringsversjoner - hver stabile versjon må alltid ha en komplett endringslogg og dokumentasjon på wikien øyeblikket den blir løslatt.

Den nøyaktige endringsloggen som sammenligner én versjon til en annen, er alltid tilgjengelig på GitHub - gjennom komma og kodeendringer. I utgivelsen anser vi gjerne for å dokumentere bare endringer som viktige mellom siste stabile og gjeldende utgivelse. Slik kort endringslogg er aldri en helt til. så hvis du ønsker å se hver endring som skjedde mellom én versjon og en annen (for eksempel oppgraderinger av avhengigheter) - vennligst bruk GitHub sammenlikning for det.

ASF-prosjektet drives av vårt kontinuerlig integrasjonsprosess. Hvert bygg skal være reproduserbar, derfor burde det ikke være et problem å gripe kilden (inkludert i utsendelsen) til en gitt versjon og sette opp samme resultat som den som finnes i våre forhåndsinnstilte binærer. Vi unngår vanligvis å kompilere selv så lenge systemene er operative, kommer frigitt binærfiler direkte fra CI-prosessen.