Hallo,
sorry für das lange Posting. Ich wollte fragen, ob es eine gängige Praxis gibt, wie man Jar-Dateien versioniert. Das man sie im SVN pflegen kann, weis ich auch. Wie siehts aber beispielsweise mit der Benamung aus? Ich mache mal ein fiktives Beispiel: Es gibt ein Projekt A, dazu die a.jar Datei. Das Projekt soll sich in der fiktiven Version 5.8 befinden.
Andere Projekte, z.B. B, C und D benötigen die a.jar Datei. Die Projekte A, B, C werden vom selben Entwicklungsteam entwickelt, teilweise auch paralell, eine neue Version von A ist im Normalfall unkritisch (verteilt durch Dateikopie, SVN etc.). Jeder Entwickler dieses Teams kann A, B, C bei sich bauen und verwalten. D allerdings muß von einem externen Entwicklungsteam aufwendig deployt und getestet werden, hier wird die a.jar beispielsweise durch Mail verteilt etc.
Man erkennt also schon mal interne (A, B, C) und externe Entwickleransichten (D).
Dazu gesellen sich Test/Produktivumgebungen von A, B, C und natürlich extern D. Insbesondere bei den Produktivumgebungen sollen Supporter kurz und knackig Antwort geben können, welche Versionen von A in B, C, D genutzt werden.
Eine Lösung und Praxis: Die a.jar Datei könnte im Dateinamen um die Versionsangabe und/oder im Manifest ergänzt werden. Beides hat Vor- und Nachteile. Sind Versionsnummern im Dateinamen, benötigt man spezielle Update/Deployverfahren, im Gegensatz zum einfachen Kopieren. Allerdings läßt sich die Version relativ leicht ablesen und nicht erst durch Öffnen der Jar.
Meines Erachtens gibt es unterschiedliche Belange (Entwicklung-Intern, Extern, Produktiv etc.) und Arten der Lösung. Was haltet Ihr davon und vor allem wie wird es bei Euch in den Firmen gemacht ? Gibt es eine "Thats It!" Lösung ?
Danke für Euer Braining und bis denne
sorry für das lange Posting. Ich wollte fragen, ob es eine gängige Praxis gibt, wie man Jar-Dateien versioniert. Das man sie im SVN pflegen kann, weis ich auch. Wie siehts aber beispielsweise mit der Benamung aus? Ich mache mal ein fiktives Beispiel: Es gibt ein Projekt A, dazu die a.jar Datei. Das Projekt soll sich in der fiktiven Version 5.8 befinden.
Andere Projekte, z.B. B, C und D benötigen die a.jar Datei. Die Projekte A, B, C werden vom selben Entwicklungsteam entwickelt, teilweise auch paralell, eine neue Version von A ist im Normalfall unkritisch (verteilt durch Dateikopie, SVN etc.). Jeder Entwickler dieses Teams kann A, B, C bei sich bauen und verwalten. D allerdings muß von einem externen Entwicklungsteam aufwendig deployt und getestet werden, hier wird die a.jar beispielsweise durch Mail verteilt etc.
Man erkennt also schon mal interne (A, B, C) und externe Entwickleransichten (D).
Dazu gesellen sich Test/Produktivumgebungen von A, B, C und natürlich extern D. Insbesondere bei den Produktivumgebungen sollen Supporter kurz und knackig Antwort geben können, welche Versionen von A in B, C, D genutzt werden.
Eine Lösung und Praxis: Die a.jar Datei könnte im Dateinamen um die Versionsangabe und/oder im Manifest ergänzt werden. Beides hat Vor- und Nachteile. Sind Versionsnummern im Dateinamen, benötigt man spezielle Update/Deployverfahren, im Gegensatz zum einfachen Kopieren. Allerdings läßt sich die Version relativ leicht ablesen und nicht erst durch Öffnen der Jar.
Meines Erachtens gibt es unterschiedliche Belange (Entwicklung-Intern, Extern, Produktiv etc.) und Arten der Lösung. Was haltet Ihr davon und vor allem wie wird es bei Euch in den Firmen gemacht ? Gibt es eine "Thats It!" Lösung ?
Danke für Euer Braining und bis denne
