Version eigene Programme?

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von Bluespide.

    Version eigene Programme?

    Guten Tag!

    Hat jemand evtl eine Quelle, wo man über Versionen lesen kann? Wie man damit umgeht, was die Good-Practices sind, Unterschied zwischen File- und Assemblyversion etc etc.

    Ich verstehe im allgemein diese Gesichte aber nicht im Detail und das will ich mittlerweile ändern.
    Z.b. Unterschied zwischen Version-, File- und Buildnumber kenne ich nicht.

    Ich frag mich warum die Nummern nicht überall "gleich lang" ist, also ich sehe evtl. 0.6.3 aber auch 0.4.2.5.1 oder z.B die Version von VS 15.1(26403.7). Warum ist es so? Beschreibt jede Nummer da was? Kann ich iwie Regeln feststellen, nach den diese Versionsnummers sind "automatisch" updaten, z.B wenn ich X mache dann soll eine neue Major Version werden...? In VS sehe ich unter Assembly-Info etwas mit dem '*', bin aber noch zu dumm es zu verstehen und noch mehr und es zu nutzen....kann da jemand helfen?

    Ich kenne die Major-Updates (neue Features bzw. große Änderungen am Code) dann wird die erste Nummer geändert. Bei kleineren Updates bzw. kleinere Fixes werden die letzteren Nummern geändert. Aber nach welchen Regeln richtet sich das alles oder welche Nummer genau werden geändert und warum ? Oder bleibt ganz offen für den Entwickler?

    Danke im Voraus :)
    Life doesn't give you a datasheet. Sometimes the docs are wrong and you have to try it.

    @rgomez Es gibt 2 Möglichkeiten, seine Version zu verwalten:

    VB.NET-Quellcode

    1. <Assembly: AssemblyVersion("1.2.3.0")>
    2. <Assembly: AssemblyFileVersion("1.2.3.4")>

    ================

    VB.NET-Quellcode

    1. <Assembly: AssemblyVersion("1.2.*")>

    ================
    Bei der zweiten Version kannst Du Dir aus den Werten das Build-Datum und Uhrzeit ausrechnen:

    VB.NET-Quellcode

    1. ''' <summary>
    2. ''' Gibt den aus der AssemblyVersion berechneten Zeitpunkt der Erstellung zurueck
    3. ''' </summary>
    4. Public ReadOnly Property BuildTime() As DateTime
    5. Get
    6. Dim version As System.Version = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version
    7. ' days since 1 January 2000
    8. ' seconds since midnight, (multiply by 2 to get original)
    9. Return New DateTime(2000, 1, 1, 0, 0, 0, _
    10. DateTimeKind.Utc).Add(New TimeSpan(TimeSpan.TicksPerDay * version.Build + TimeSpan.TicksPerSecond * 2 * version.Revision))
    11. End Get
    12. End Property

    Was Du nun als Werte da einträgst, bleibt Dir überlassen.
    Bei uns hat sich eingebürgert, jedes Upgrade oder jedes Jahr die 1. Stelle zu erhöhen, jedes Update die 2. oder 3. Stelle, je nach Umfang.
    Die 4. Stelle nach Absprache.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Das liegt daran, dass es verschiedene Formate gibt. Die Standard-Variante wird auf Wikipedia sehr gut beschrieben: de.wikipedia.org/wiki/Versionsnummer siehe vorallem:

    https://de.wikipedia.org/wiki/Versionsnummer schrieb:

    Hauptversionsnummer
    (englisch: major release) indiziert meist äußerst signifikante Änderung am Programm – zum Beispiel wenn das Programm komplett neu geschrieben wurde (zum Beispiel GIMP 2.x nach der Version 1.x) oder sich bei Bibliotheken keine Schnittstellenkompatibilität aufrechterhalten lässt.

    Nebenversionsnummer
    (englisch: minor release) bezeichnet meistens die funktionale Erweiterung des Programms.

    Revisionsnummer
    (englisch: patch level) enthält meist Fehlerbehebungen.

    Buildnummer
    (englisch: build number) kennzeichnet in der Regel den Fortschritt der Entwicklungsarbeit in Einzelschritten, wird also zum Beispiel bei 0001 beginnend mit jedem Kompilieren des Codes um eins erhöht. Version 5.0.0-3242 stünde also für das 3242. Kompilationsprodukt einer Software. Verwendet man Versionskontrollsysteme, so wird an Stelle der Build-Nummer gerne eine Nummer verwendet, die die Quellen zum Kompilat innerhalb des Versionskontrollsystems eindeutig identifiziert. Das erleichtert im Fehlerfall, die zugehörigen Quellen zu finden.


    Es gibt jedoch keine eindeutigen Regeln, häufig ist es z. B. so, dass die Hauptversionsnummer zu Marketing-Zwecken sinnlos erhöht wird.
    Leider ist es nun so, dass das zwar alles sehr gut und logisch ist, aber leider für Anwendungen eher suboptimal. Deshalb gibt es Semantic Versioning
    Die Vorteile werden hier ganz gut dargestellt: sitepoint.com/semantic-versioning-why-you-should-using/
    Mfg
    Vincent

    Vielen Dank, jetzt verstehe ich es viel besser.

    zusammengefasst für meine Kontrolle:
    • Also gibt keine feste Regeln
    • Muss nicht unbedingt sinnvoll benutzt werden, sollte man aber 'to keep things clean & organized'
    • Für Updates oder evtl. bestimmente Sachen anzeigen oder erlauben anhand der Version sehr hilfreich
    Danke @VincentTB für den Link, das werde ich mal ausprobieren und @RodFromGermany über die Erklärung, endlich verstehe ich '*' :)
    Life doesn't give you a datasheet. Sometimes the docs are wrong and you have to try it.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „rgomez“ ()

    rgomez schrieb:

    und ErfinderDesRades über die Erklärung
    Wer :?:
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

Facebook
Telefonspende