Nieuws
image

Oracle onthult nieuw plan voor Java-versienummers

donderdag 16 mei 2013, 11:41 door Redactie, 8 reacties

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.

Reacties (8)
16-05-2013, 12:56 door N4ppy
ehhhh help?

Is er ook een versie "de laatste"?

Wat een gedoe met nummers zeg
16-05-2013, 13:54 door Anoniem
Ik heb al JAAAAREN geleden gewoon als onderdeel van het versienummer yyyymmdd ingevoerd bij mijn eigen spullen.
Nooit meer verwarring over wat is nieuwer en van wanneer is ie ongeveer.
16-05-2013, 14:05 door [Account Verwijderd]
[Verwijderd]
16-05-2013, 14:16 door Anoniem
wat is er toch mis met major.minor.patchlevel?

Misschien moeten ze omlaag gaan nummeren, aftellen naar het moment dat ze java definitief om zeep hebben geholpen.
16-05-2013, 15:27 door Anoniem
Door Anoniem: Ik heb al JAAAAREN geleden gewoon als onderdeel van het versienummer yyyymmdd ingevoerd bij mijn eigen spullen.
Nooit meer verwarring over wat is nieuwer en van wanneer is ie ongeveer.

dus iets als
<major>.<minor>.<timestamp>?
16-05-2013, 16:14 door lucb1e
Door Anoniem: wat is er toch mis met major.minor.patchlevel?
Dat was ook mijn eerste gedachte. Op deze manier wordt het totaal onlogisch.

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.
17-05-2013, 10:12 door Anoniem
Door Anoniem:
Door Anoniem: Ik heb al JAAAAREN geleden gewoon als onderdeel van het versienummer yyyymmdd ingevoerd bij mijn eigen spullen.
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.
17-05-2013, 23:26 door Anoniem
Door Anoniem:

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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search