Nach der Babypause sind Tom und André wieder frisch und ausgeruht zurück. In dieser Episode wird über die Google I/O Keynote, Android L, Android Wear, Android TV und alle sonstigen Errungenschaften der Konferenz aus SF gesprochen. Danach gibt es einen kleinen Exkurs in die Thematik der Versionsnummern, sowie ein paar Groovy und Grails Programmierthemen. Zu guter Letzt werden die DTR.fm Höhrerzahlen verkündet. Man darf gespannt sein.
Shownotes
Ich habe gerade einen Blogost über Hibernate und Webflow geschrieben:http://hygl.github.io/spring/2014/05/28/lazyloading-jpa-and-spring-webflow
Interessante Variante, muss ich mir beim nächsten WebFlow noch mal im Detail anschaun.
Auf jeden Fall gut dass du Hibernate.initialze() losgeworden bist, das sollte man nicht brauchen.
Hallo Tom und André!
Unser Produkt ist zwar nicht im Web sondern eine Windows-Anwendung, aber trotzdem hier unsere Branching-Strategie:
Die sieht dem aus dem Artikel “A successful Git branching model” sehr ähnlich.
Im Grunde gibt es einen Hauptentwicklungs-Branch an dem immer für die neue Version entwickelt wird. Die Versionsnummer ist immer die für die neue Version, d.h. wenn an der Version 1.0 entwickelt wird, ist die Version am Entwicklungsbranch 1.0.
Sobald die Version 1.0 released wird, wird die Version “1.0” getaggt und von diesem Tag ein “Release-Branch” angelegt. In diesem Release-Branch werden dann Bugfixes für Hotfixes und Service Packs eingecheckt.
Der Haupt-Entwicklungsbranch bleibt immer der gleiche. Nach dem Anlegen des Release-Branchs “1.0” wird die Version am Entwicklungsbranch sofort auf die nächste Versionsnummer “2.0” umgestellt.
Wir haben Continuous Integration und Daily Builds (oder auch öfter). Mit jedem Build wird die Build-Number um 1 erhöht, da potentiell jeder Daily Build zum Kunden kommen kann (z.B. für das Early-Access-Programm).
Unsere numerische File-Version besteht aus 4 Teilen. … z.B. 1.0.1.3433 (Windows “File Version” Format).
Hi Philip,
danke für deine Info.
Eine Frage dazu: commited ihr (bzw euer Buildserver) die Buildnummern ins Repository?
Ja, die Buildnummer wird committet. Aber darüber kann man streiten.
Vorteile: Sichtbarkeit der Buildstände (was ist drin?) im Repo, ausschecken und genau die Version bauen ist leicht möglich.
Nachteil: “Noise” in der History. Änderungen, die keine Änderungen sind.
Hi,
leider waren wieder einige Störgeräuche im Podcast zu hören. Ab Minute 30 wurde es dann besser.
Hi,
ja leider haben wir es zu spät gemerkt dass mein USB Mikro komisch verzerrt hat.
Wir tun unser Bestes um die Audioqualität hoch zu halten aber manchmal schleichen sich Fehler ein.
Der JS Player ist super 🙂 Und auf iOS wird das ganze ja direkt in den Audiocontext vom Phone geladen, d.h. ich kann das nachher normal bedienen wie aus iTunes oder sonstwas raus. Btw.: Download-Button wär nett, falls der Player mal auf iOS wieder versagt 😉
Und die Web-Sachen der Google IO kann man sich auch ansehen. Polymer und Service Worker z.B. sind äußerst interessant. Und Jake Archibald und Alex Russel sind Comedy Gold: https://www.youtube.com/watch?v=_yy0CDLnhMA – sehr zu empfehlen!
Zum Thema versionierung bin ich letztens über zwei interessante links gestolpert:
* Semantic Versioning Specification (http://semver.org)
* Java SemVer – an implementation of the Semantic Versioning Specification (https://github.com/zafarkhaja/java-semver)
zweiteres lässt sich auch gut in verbindung mit Gradle benutzen.
Ansonsten weiter so!
viele grüße,
rene