Oracle onthult nieuw plan voor Java-versienummers
Vanwege het grote aantal noodpatches dat Oracle de afgelopen maanden voor Java moest uitbrengen, gaat het een nieuwe nummering hanteren. Oracle brengt elke vier maanden een Critical Patch Update (CPU) uit, waarvan de versienummers vaak al vast stonden. Vanwege noodpatches moesten die versienummers eerder worden gebruikt en de eerder uitgegeven nummers aangepast.
Java gebruikt op dit moment een nummer voor de releaseversie en een getal voor de update. Java 7 Update 21 is op dit moment de meest recente versie. Om meer ruimte voor de noodpatches te maken zonder de vooraf aankondigde nummering te verstoren, is er een nieuw plan onthuld.
Nummering
Voor Limited Updates, die geen beveiligingsfixes bevatten, wordt er met twintigtallen gewerkt. De volgende Limited Update voor Java 7 zal dan ook Java 7 Update 40 zijn, gevolgd door Java 7 Update 60. Voor de CPU-versienummers werd traditioneel met oneven getallen gewerkt.
Dat zal nog steeds zo blijven, maar worden er nu steeds vijftallen bij de laatst verschenen Limited Updates opgeteld. De komende drie CPUs krijgen dan ook versienummers Java 7 Update 45, Java 7 Update 51 (CPU werkt alleen met oneven nummers) en Java 7 Update 55.
Vervolgens staat Limited Update Java 7 Update 60 gepland, gevolgd door Java 7 Update 65, Java 7 Update 71 en Java 7 Update 75. Zodoende is er in het geval van noodpatches voldoende ruimte om de overgebleven versienummers te gebruiken, aldus Oracle.
Is er ook een versie "de laatste"?
Wat een gedoe met nummers zeg
Nooit meer verwarring over wat is nieuwer en van wanneer is ie ongeveer.
Misschien moeten ze omlaag gaan nummeren, aftellen naar het moment dat ze java definitief om zeep hebben geholpen.
Nooit meer verwarring over wat is nieuwer en van wanneer is ie ongeveer.
dus iets als
<major>.<minor>.<timestamp>?
Op een developersforum hebben we eens een discussie over versienummers gehad, en vrijwel iedereen was het unaniem eens over major.minor.patch. Getuige daarvan is de grote hoeveelheid applicaties die die structuur ook gebruiken.
Er is ook nog wat te zeggen voor een simpel incrementeel nummer te gebruiken, maar dat is eigenlijk alleen handig voor applicaties die nog sterk in beta zijn. Niet echt geschikt voor releases.
Ik heb zelf een keer (jaren geleden) ook iets dergelijks gebruikt als wat Oracle nu doet, waar 1.x een stable release was, 2.x een beta, 3.x weer een stable, enz. Na een tijdje was het gewoon echt niet meer bij te houden welke nou wat was. Ik kon toen tenminste nog een oneindig aantal patches uitbrengen binnen versie 1.x of beta 2.x, daar limiteert Oracle zichzelf nu ook in. En niet met een logisch nummer zoals 10 of 100, nee 5 en 20. Ik gok dat Oracle hetzelfde probleem gaat ervaren als ik toen, maar dat zij er vervolgens gewoon meer documentatie tegenaan gooien. Dat is minder werk (en minder een afgang) dan het opnieuw wijzigen van de publieke versienummering.
Nooit meer verwarring over wat is nieuwer en van wanneer is ie ongeveer.
dus iets als
<major>.<minor>.<timestamp>?
Ja inderdaad.
Als er geen parallelle ondersteuning van meerdere versies is (bijvoorbeeld een hobby projectje) dan zelfs alleen een timestamp.
Waar veel mensen (ook Orcacle) ook niet aan denken is dat het handig is om je versienummer zo te structureren
dat je zowel in numerieke als in ASCII sortering een oplopende volgorde krijgt.
Dus niet een 7.0.99 uitbrengen en daarna een 7.0.100
Dit betekent van te voren inschatten hoeveel nummeringen je op een level wilt gebruiken en de juiste veldbreedte
kiezen met 0-padding.
Met dat timestamp veld gaat dat prima, maar met een patch- of buildnummer gaat het vaak fout.
Waar veel mensen (ook Orcacle) ook niet aan denken is dat het handig is om je versienummer zo te structureren
dat je zowel in numerieke als in ASCII sortering een oplopende volgorde krijgt.
Dus niet een 7.0.99 uitbrengen en daarna een 7.0.100
Dit betekent van te voren inschatten hoeveel nummeringen je op een level wilt gebruiken en de juiste veldbreedte
kiezen met 0-padding.
Met dat timestamp veld gaat dat prima, maar met een patch- of buildnummer gaat het vaak fout.
Inderdaad. Dan heb je van die software die na 1.9 opeens naar 1.10 gaat en dan sta ik toch even raar te kijken. Eigenlijk is het best logisch maar m'n hoofd kan er toch niet tegen. 1.09 naar 1.10 daarentegen, niks moeite mee.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
