Veröffenlichung

  • Allgemein

Es gibt 14 Antworten in diesem Thema. Der letzte Beitrag () ist von Scotty.

    Veröffenlichung

    Hi bin Neu noch hier im Forum und weiß noch nicht genau wo man wie was hin postet fragen etc.

    Deswegen mache ich es mal hier:

    Hauptversion

    Nebenversion

    Build

    Revision (ändert sich automatisch)

    Was Bedeuten diese Begriffe Hauptversion ist mir Klar, aber was bedeuten die anderen 3 und wann

    muss ich eine weiter Zahl rein machen.

    ----

    Was muss ich noch bei der Veröfflichung beachten hab nehmlich noch nie richtig ein Veröffendlicht?



    --

    Hey,
    ich dachte immer Build kommt nach Revision? Naja, egal.

    Also, das Ganze funktioniert so:

    Hauptversion wird nur geändert, wenn bspw. die Engine neugeschrieben wurde,
    Nebenversion wird geändert, wenn bspw. neue Funktionen hinzugefügt wurden,
    Revision wird bspw. ein Bug gefixt wurde und
    Build wird bei jedem erstellen automatisch erhöht.

    MfG,
    -haiyyu

    Hi!
    Ich hätte es zwar etwas anders ausgedrückt, aber prinzipiell stimmt es: Deine Begriffe in eine übliche Suchmaschine eingegeben, fördert dies zutage. Hier wird sehr gut erklärt, was sich MS bei diesen Begriffen gedacht hat

    Versionsnummern bestehen aus zwei bis vier Komponenten: Haupt- und Nebenversion sowie Build- und Revision. Die Haupt- und Nebenkomponenten sind erforderlich; die Build- und Revisionskomponenten sind optional, allerdings ist die Buildkomponente erforderlich, wenn die Revisionskomponente definiert wurde. Alle definierten Komponenten müssen ganze Zahlen größer oder gleich 0 (null) sein. Die Versionsnummer muss folgendem Format entsprechen. Optionale Komponenten werden in eckigen Klammern ("[" und "]") angezeigt.

    major.minor[.build[.revision]]

    Die Komponenten werden konventionsgemäß wie folgt verwendet:

    Major: Assemblys mit demselben Namen, aber unterschiedlichen Hauptversionen sind nicht austauschbar. Dies würde sich z. B. für eine neue Produktversion mit so gravierenden Änderungen anbieten, dass Abwärtskompatibilität nicht vorausgesetzt werden kann.

    Minor: Wenn der Name und die Hauptversionsnummer für zwei Assemblys gleich sind, die Nebenversionsnummern sich jedoch unterscheiden, weist dies auf eine wesentliche Verbesserung hin, bei der jedoch eine Abwärtskompatibilität angestrebt wurde. Dies wäre z. B. für eine Point Release eines Produkts oder eine vollständig abwärtskompatible neue Version eines Produkts geeignet.

    Build: Eine unterschiedliche Buildnummer verweist auf eine Neukompilierung desselben Quellcodes. Dies bietet sich bei Prozessor-, Plattform- oder Compileränderungen an.

    Revision: Assemblys mit demselben Namen, derselben Haupt- und Nebenversionsnummer, aber unterschiedlichen Revisionen sollen vollständig austauschbar sein. Dies bietet sich für die Beseitigung von Sicherheitsmängeln in einer zuvor veröffentlichten Assembly an.


    LG, der_Kurt

    kevin89 schrieb:

    Ab 1.0.0.0 ist es dann keine Beta mehr.
    Es gibt doch Beta mit Major-Version ab 1 z.B. Windows 7 hat Version 6.1 Beta :rolleyes:

    @Neu: du kannst dein Version mit Beta z.B. in der Titelleiste z.B. "1.0.2 Beta" machen. Du kannst die Version-Werte aber nur Nummer (wegen Integer!!) im Eigenschaft eingeben. Nur Beispiel!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „tcs-1986“ ()

    Ist doch echt Jacke wie Hose, ist keine Diskussion wert, jeder macht das anders, hier gibt es keine wirklichen Regeln bzw. Vorschriften...

    Bei mir gibt die letzte Nummer beispielsweise das Jahr und die Nummer des wievielten Release in dem Jahr an. Also beispielsweise Version 1.01.20092 (der zweite Release im Jahr 2009). Ob es eine Beta ist oder nicht steht nirgends, außer auf der Webseite, in der Readme und das Release-Datum ist in der Info-Form nicht angegeben.

    Wie gesagt, jeder macht es anders...

  • 3 Benutzer haben hier geschrieben

Facebook
Telefonspende