Software-update: LibreOffice 24.2.0

De Document Foundation heeft versie 24.2.0 van LibreOffice uitgebracht. Dit opensource-officepakket is ontstaan als afsplitsing van OpenOffice en wordt geleverd met tekstverwerker Writer, spreadsheetprogramma Calc, presentatieprogramma Impress, tekenprogramma Draw, databaseprogramma Base en Formula, een applicatie om wetenschappelijke notaties mee te maken. Uitgebreide releasenotes zijn op deze pagina te vinden, dit zijn in het kort de belangrijkste veranderingen:

General

• Support for zoom gestures when using touchpads in the main view.
• Support for document themes, and import and export of theme definitions for ODF and OOXML documents.
• Many improvements to font handling, especially for right-to-left scripts, CJK and other Asian alphabets.

Writer

• New Page Number Wizard in the Insert menu, for easy one-step insertion of the page number in the header/footer.
• The Paragraph Style dropdown in the Formatting toolbar shows a list of styles used in the document, rather than the full list of the available styles.
• Tables of Figures can be generated more flexibly based on paragraph styles, and not only from categories or object names.
• Bibliography entries can be edited directly from a bibliography table, and bibliography marks hyperlink by default to the matching row in a bibliography table.
• Highlighting for used paragraph and character styles and direct formatting in text.
• Phrase checking: multi-word dictionary items of Hunspell and custom dictionaries are now accepted.

Calc

• Number format: “?” is now supported when exporting to ODF to represent an integer digit, replaced by blank if it is a non significant zero, and decimals for formats in seconds without truncation like [SS].00 are now accepted.
• Spreadsheets copied to another document now retain a user-defined print range.
• Solver settings are saved with documents, and page styles are exported even if they are not in use.
• Support for drawing styles for shapes and comments, including a dedicated style for comments that makes it possible to customize the default look and text formatting of new comments.
• New compact layout for pivot tables.
• Autofilter support for sorting by colour. Filter/sort by color considers colours set by number format.
• The Import Text dialog (as CSV file or as unformatted text) has a new option to not detect number in scientific notation (only if “Detect Special Numbers” is off).

Impress & Draw

• New navigation panel for switching slides while viewing a presentation (option is enabled by flagging a checkbox in Slide Show Settings).
• Objects can now be listed in front to back order in the Navigator, with the top-most object at the top of the list.
• Support for free text annotations to PDFium import, plus support for ink, free text and polygon/polyline annotations in PDFium export.
• Modified the auto-fitting text scaling algorithm to work in a way similar to MS Office. Text scaling now separates scaling for space (paragraph and line) and scaling fonts, where space scaling can be 100%, 90% and 80%, and font scaling is rounded to the nearest point size. Horizontal spacing (bullets, indents) is not scaled anymore.
• Several improvements to font management for CJK and Arabic languages.

Versienummer	24.2.0
Releasestatus	Final
Besturingssystemen	Linux, macOS, Windows 10, Windows 11
Website	The Document Foundation
Download	https://nl.libreoffice.org/download/libreoffice-nieuwste-versie/
Bestandsgrootte	346,67MB
Licentietype	GPL

Reacties (37)

[NEO256]

Een notitie waarom de nummering ineens anders is:
https://www.phoronix.com/news/LibreOffice-24.2-Up-Next

One nugget of information in the LibreOffice 7.6 release announcement for those who missed it and deserves calling out specifically... Succeeding LibreOffice 7.6 will not be v7.7 or v8.0 but rather v24.2.

LibreOffice developers are moving to a year.month based versioning system

[Anoniem: 24916]

Veel duidelijker, zou meer software moeten doen.
7Zip is daar ook mee begonnen, al is dat natuurlijk maar een zéér klein programmatje vergeleken met LibreOffice.

[guillaume]

Ik zou niet weten waarom dit een nuttige manier van versioning is. Als je op 31 januari 2024 kijkt een programma dat deze versienummers aanhoudt, dan kun je daaruit totaal niet opmaken: de laatste versie kan evengoed nog v22.9 zijn.

Wat nog erger is met zoiets, is dat je helemaal geen idee meer hebt of je te maken hebt met een grote update met flinke veranderingen die daadwerkelijk voor problemen kunnen zorgen, een "middelgrote" update met nieuwe features, of een kleine release met wat bugfixes (semantic versioning).

Een jaar.maand-format vind ik echt een idiote manier van doen.

[aileron]

Als ik LibreOffice 7.5 heb, zegt dat niet meteen iets over hoe nieuw deze release is. Als ik over drie jaar nog versie 24.2 draai ga ik toch eens kijken waarom ik nog niet geupgrade ben.
Daarnaast, soms lees je nieuws over nieuwe features die zijn gemaakt voor software. Als je dit vorige week gelezen hebt dan snap je dat je release van 25 moet hebben om die feature te hebben. Als in het artikel stond dat het vanaf versie 7.6.3.2 is ga je dat nooit onthouden.

Bij ubuntu is nog relaxer omdat ik vantevoren weet dat bij even jaren in april een lts versie uitkomt. Debian heeft ook een redelijk stabiele release schedule maar die zou ik je niet zo kunnen vertellen. Bij ubuntu wel

Genoeg voorbeelden?

[guillaume]

Het absolute versienummer 7.5 zegt inderdaad niks meer over tijd, maar wel al wat over hoe "mature" bijv. v7.5 binnen de v7-tak is. Daarnaast lijkt 't bij jou alleen te gaan over de vraag "heb ik wel de laatste versie?", terwijl het 't mij meer om de "versieverschillen" gaat en dat je dan ook beter kunt inschatten wat je moet verwachten als je de update voltrekt. Dat voordeel is in z'n totaliteit verdwenen bij zulke jaar.maand-versienummers.

Wat betreft nieuwe features die zijn aangekondigd zou je voorbeeld met "dat je release van 25 moet hebben" helemaal niet opgaan (tenzij de feature echt pas volgend jaar zou worden geïntroduceerd), want die nieuwe feature kan nu in 24.3, 24.4, 24.5, 24.6 of welke dan ook pas geïntroduceerd worden (want er kunnen allemaal minimale bugfixreleases tussen zitten, terwijl het door de versiestap een even grote update lijkt). Rekenend vanaf 7.5 zou het logische gevolg zijn dat de nieuwe feature te verwachten is in 7.6 of eventueel 8.0.

Wat betreft Ubuntu (of überhaupt een OS) begrijp ik 't nog wel, zoals ik eerder al aangaf.

[sebati]

Wat betreft nieuwe features die zijn aangekondigd zou je voorbeeld met "dat je release van 25 moet hebben" helemaal niet opgaan (tenzij de feature echt pas volgend jaar zou worden geïntroduceerd), want die nieuwe feature kan nu in 24.3, 24.4, 24.5, 24.6 of welke dan ook pas geïntroduceerd worden (want er kunnen allemaal minimale bugfixreleases tussen zitten, terwijl het door de versiestap een even grote update lijkt). Rekenend vanaf 7.5 zou het logische gevolg zijn dat de nieuwe feature te verwachten is in 7.6 of eventueel 8.0.

Dat is nu precies het punt; het release-small-release-often model zorgt voor inrementele verbetering zoals die bij veel toepassingen worden doorgevoerd. Om functionele- en beveiligings verbeteringen te kunnen doorvoeren vereist dit veelal technische aanpassingen (afhankelijkheden) binnen de toepassing. Als je met verouderde afhankelijheden werkt kun je aanpassingen niet maken en wordt je uiteindelijk gedwongen om een major release te doen waar dan ontzettend veel aanpassingen in zitten en waar de kans op fouten dus statisch gezien ook veel groter is. Alle ontwikkelde functies worden namelijk in een keer worden vrijgeggeven. Vervolgens moet je twee branches van de software onderhouden, de oude versie en de nieuwe versie. Tenzij hier betalende klanten tegenoverstaan die onderhoud afnemen is het voor veel projecten ondoenlijk om meerder branches (goed) te onderhouden, het kost namelijk tijd. Die tijd gaat dan ten koste van nieuwe ontwikkelingen, zowel noodzakelijke als wenselijke verbeteringen. Zo'n major release wordt, doordat niet veel mensen direct overstappen, dan ook nog eens minder goed getest waardoor fouten en regressies minder snel worden ontdekt en opgelost wat nog meer mensen ertoe aanzet om niet over te stappen. Marjor-minor is daarmee ook een Self-fulfilling prophecy voor de aanname dat er meer fouten in een major release zitten.
De "LibreOffice 8" release wordt al een tijd over gesproken, wat zou dit betekenen? Dat schept hoge verwachtingen die wellicht niet realistisch zijn. Er is namelijk niet een enkele functie die zo'n major versie nummer rechtvaardigd. Daar kun je natuurlijk een mening over hebben, maar realiteit is dat release-small-release-often zorgt voor stabiele incrementele verbeteringen waarbinnen wijzingen eerst in experimentele fase wordt gezet (die moet je dus activeren om te kunnen gerbuiken) en pas als de ontwikkelaars tevreden zijn voor iedereen beschikbaar komen. De enige reden voor een versie 8 die in mij opkomt is een "GUI refresh"; hier zijn veel ideeen over maar heeft veel impact en is heeeel veel werk, wat ten koste gaat van andere ontwikkelingen. Hiervoor moet onder de motorkap ook nog veel worden gedaan en juist dit werk wil je niet in een major release vrijgeven omdat er wellicht echt veel stuk zou kunnen gaan. LO draait nou eenmaal niet enkel op Windows, maar ook MacOS, Linux en heeft een schil voor Gnome en KDE. Als je de ontwikkelaars van LO een beetje volgt dan weet je dat ze hiermee erg voorzichtig zijn.

[locke960]

Het probleem is dat het idee incrementele verbeteringen in de praktijk vooral resulteert in incrementele veranderingen.

Veranderingen ≠ verbeteringen. Om de haverklap weer een verandering, met name in de gebruikerservaring, is irritant en frustrerend, vooral als het automatisch gebeurd, zonder aankondiging en keuze.

[sebati]

Wanneer je geen vereberting/verandering wilt dan moert je gewoon een oude versie blijven gebruiken. Je kunt (open source) ontwikkelaars die hun software 'gratis' aanbieden niet kwalijk nemen dat ze een oude versie van de software op een bepaald moment niet verder ontwikkelen. Wanneer je dat wel wilt is er de optie om dat zelf te doen (veel plezier met backporten van patches) of de optie om een betaalde Long Term Support versie van (in dit geval) LibreOffice af te nemen, bijvoorbeeld bij Allotropa of Collabora. Met een betaalde LTS versie kun je 10+ jaar ondersteuning ontvangen, dat is voor de meeste bedrijven wel genoeg. Als consument die voor 'gratis' gaat heb je weinig keus en lijkt het me nogal ongepast om te klagen dat de ontwikkelaars 'bepalen' wat de update cadans is.

[guillaume]

Dat is nu precies het punt; het release-small-release-often model zorgt voor inrementele verbetering zoals die bij veel toepassingen worden doorgevoerd

Ik begrijp dat dat een doel kan zijn, maar iedere breaking change zal gewoon in zo'n jaar.maand-release verstopt zitten. Bovendien denk ik niet dat semantic versioning in de weg staat van release-small-release-often: het hoeft echt alleen maar een (in mijn ogen veel informatievere) manier te zijn voor versienummers. Dat was ook mijn punt, niet zozeer of het (al dan niet inherent) een geheel andere manier van releasen zou kunnen behelzen of zelfs afdwingen.

Het bijhouden van twee (of meer) branches zie je evengoed bij andere releasemodellen (bijv. LTS).

Onder de streep denk ik dat de development cycle niet per definitie gekoppeld hoeft te zijn aan de mate waarin je het versienummer informatief houdt m.b.t. (breaking) changes. Een nieuwe major versie zou bij mij overigens ook niet direct zorgen voor terughoudendheid bij of zelfs uitstel van de update, maar wel dat ik bijgaande blogposts over de release met meer aandacht zal bekijken i.p.v. alleen maar de changelog te scannen. Het is ook een indicatie of de update an sich een snelle handeling zal zijn of eventueel voor meer werk zal zorgen. Daar zie ik gewoon een groot voordeel.

[Reactie gewijzigd door guillaume op 22 juli 2024 15:27]

[sebati]

Deels met je eens, snap het punt dat je maakt. Natuurlijk zou je beide versie nummer systemen kunnen hanteren met de argumenten die je aangeeft. Echter doordat (in dit geval) LibreOffice -continue- de benodigde aanpassingen maakt om de voortgang te optimaliseren met berperkingen zoals ontwikelaar capaciteit en budget en functionele eisen die er zijn, is er niet iets waar aan ontwikkeld wordt dat een major versie nummer 'rechtvaardigd'. Dit is waarom we hebben gezien dat versie 7.x is opgerekt tot 7.6 terwijl voorheen slecht 3 release binnen een major versie werd aangehouden. Versie 24.2 had dus net zo goed 7.7 kunnen zijn, en zo verder todat... Dat maakt het op termijn des te onduidelijker hoe oud de 'versie' uiteindelijk is, voor de gebruiker namelijk nog steeds '7' en dus kom je gevoelsmatig in een situatie waarin OpenOffice ook is beland. Hier zie je al bijna 10 jaar 4.1.x met weinig veranderingen tot in 4.1.15. Daarintegen iedere 7.x release van LO en 7.x.y release van LibreOffice heeft veel features in x en fixes in de y releases. Dit is voor gebruikers niet duidelijk die geen release notes of blog posts lezen. Gebruikers willen gewoon dat het werkt. Gezien patch y om de 6 weken uitkomt en er zes patch releases zijn, heeft iedere 7.x release dus een support cycle van slechts 36 weken. Een major release, met het voorbeeld zoals 'LibreOffice 8' zou kunnen duiden op breaking changes, zoals een nieuwe GUI... maar zoiets is -jaren- werk onder de motorkap en heeft een heel hoog risico op het breken van onderliggende afhankelijkheden met daarnaast alle GUI varianten die LO ondersteund. Om een voorbeeld aan te halen: GIMP, dat al jaren werkt aan versie 3 om van GTK2 naar 3 te komen, dat is een major release met breaking changes (bv plugins, API) en functionaliteit waar jaren is gewerkt en ook pas beschikbaar zal komen voor gebruikers op het moment zij 3.0 zullen gaan installeren. Dit is precies wat LibreOffice wil vookomen. Is er een goed en slecht model? Nee, het is gewoon een praktische keuze van het ontwikkelteam. Bij LibreOffice speelt ook nog mee dat er ecosyteem partners zijn die worden betaald om functionaliteit aan LibreOffice toe te voegen. Dat kan niet wachten op zo'n major release die mogelijk pas jaren later kan verschijnt; binnen het huidige model worden vrijwel alle ontwikkelingen beschikbaar in de volgende release, de voorjaar (februari) of de najaar (augustus) release, dat maakt het voor partners en daarmee voor betalende klanten dus voorspelbaar. LibreOffice is meer dan een editor, het is ook basis voor de LTS versies van ecosysteempartners en producten die met 'LO Technnologie' worden gebouwd zoals de Online editor Collabora Online (COOL/CODE) en de WebAssembly versie (LOWA) welke ook met regelmaat infrastructurele aanpassingen binnen vereisen.

[Reactie gewijzigd door sebati op 22 juli 2024 15:27]

[guillaume]

Ik denk dat ik wat "minder rigide" denk over wat een major version moet inhouden en daarmee rekening houdend zouden we denk ik al een heel eind dichter bij elkaar in de buurt komen. Thanks voor de in-depth info over de development cycles!

[sebati]

Bedankt, goede inhoudelijke discussie!

[scholtnp]

Voor een Linux distributie zoals Ubuntu vindt ik het wel een goed idee, omdat het aangeeft of die wel of niet bij de tijd is. Maar voor alle programma's daarin is het niet echt zinvol. Je wilt inderdaad weten of iets slechts een kleine bugfix is of dat alle GUI's, configuratie e.d. anders zijn en je wel even bezig bent om opnieuw je werkflow te moeten aanpassen.

[guillaume]

Met LTS-releases wordt 't alweer snel verwarrend, vind ik (bijvoorbeeld nu Ubuntu 22.04, da's de laatste), maar ik snap 't bij een OS nog enigszins ja. Toch vind ik de manier waarop bijvoorbeeld Apple z'n versiebeheer doet toch informatiever.

[Reactie gewijzigd door guillaume op 22 juli 2024 15:27]

[Zidane007nl]

Waarom is het verwarrend? LTS releases van Ubuntu, die elke 2 jaar uitkomen, worden standaard 5 jaar ondersteund. Dus als je nog op 20.04 zit, dan is deze nog ondersteund tot april 2025.
Zie ook https://endoflife.date/ubuntu.

[Reactie gewijzigd door Zidane007nl op 22 juli 2024 15:27]

[guillaume]

Agreed, zodra je met deze achtergrond bekend bent, dan is 't wel nuttig voor een OS als Linux, zeker omdat dat vnl. een verzameling van (kernel +) een heleboel pakketten is. De veranderingen zijn vooral in die losse softwarepakketten aangebracht en zijn dus daar terug te vinden.

Bij Apple (of iOs, of Android bijvoorbeeld) geldt dat wat minder, omdat het een OS-update ook echt brengt met nieuwe features die exclusief zijn voor dat OS.

[Reactie gewijzigd door guillaume op 22 juli 2024 15:27]

[rbr320]

Toch vind ik de manier waarop bijvoorbeeld Apple z'n versiebeheer doet toch informatiever.

Wat is er informatief aan een arbitrair gekozen versienummer, zelfs al voldoet het aan de semver standaard?

[wimhey]

Helemaal akkoord. Eerste nummer is dan een grote nieuwe versie, tweede nummer voor kleine wijzigingen en het derde nummer voor het oplossen van bugs. CR 1 tot 3, candidate releases voor de definitieve uitgave na de beta versies. Kan het niet duidelijker?

[Reactie gewijzigd door wimhey op 22 juli 2024 15:27]

[sebati]

Als je je wat had verdiept in de reden van de versie nummering wijziging dan had je geweten dat, net als bij veel andere software het geval is, tegenwoordig nummering veelal gebaseed is op jaartal.maand (sommige oplossingen gebruikten jaar.kwartaal, jjjj.mm, ...). Reden is dat dit de gebruiker beter informeerd over hoe "oud" de software is die wordt gebruikt. Dat is namelijk lastig bij een incrementeel versie nummering zoals 5.x.y, 6.x.y, 7.x.y en geeft de gebruiker geen enkele informatie over het feit dat de gebruikte versie mogelijk sterk verouderd is. UIteindelijk is het maar een nummer...

Wat nog erger is met zoiets, is dat je helemaal geen idee meer hebt of je te maken hebt met een grote update met flinke veranderingen die daadwerkelijk voor problemen kunnen zorgen, een "middelgrote" update met nieuwe features, of een kleine release met wat bugfixes (semantic versioning).

Het release model van een grote update met supportpacks en patches gedurende een lange periode is achterhaald. Voorheen waren er immers veel bedrijven die bewust een stratgie hadden om een versie achter te lopen in de hoop dat een ander dan vast de bugs zou ondervinden en deze opgelost zouden zijn tegen de tijd dat zij zelf zouden updaten. Tegenwoordig zie je veelal dat je meer problemen hebt of meer risico loopt wanneer je (te) ver achterloopt dan wanneer je mee blijft lopen met de meest recent updates. Om verbeteringen te kunnen doorvoeren, met name op het gebied van beveiliging en afhankelijkheden zijn veelal infrastructurele aanpassingen binnen de software vereist. Dit zijn over het algemeen zaken die voor de ontwikkelaards meer impact hebben dan voor de gebruikers, die van aanpassingen "onder de motorkap" geen last hebben, maar voor ontwikkelaars essentieel zijn gezien het onderhouden van verouderde afhankelijkheden voor ontwikkelaards ontzetten veel extra tijd kost en daarmee ook de innovatie remt. Arbeid is schaars, ook binnen open source projecten, dus er is over het algemeen niemand die de ontwikkelaars "betaald" om oude versies en afhankelijkheden te onderhouden. Afgelopen jaren is software ontwikkeling in veel gevallen overgegaan naar een release-small-release-often model. Daarintegen, wat jij zelf ook al aangeeft, het "oude" major.minor model schept een verwachting over "grote" wijzigingen in iedere major release, maar heeft ook als resultaat dat gebruikers of bedrijven dit er doorgaans van weerhoud om regelmatig te upgraden, omdat zij vaak denken dat er dan ook mogelijk nog wel veel bugs in zullen zitten. Het release-small-release-often model zorgt ervoor dat (infrastructurere) zaken die nodig zijn "gewoon" kunnen worden uitgevoerd en een balans in vernieuwing, bug fixes en beveiligingverbeteringen in iedere release kunnen worden meegenomen op het moment dat dit nodig is. Veel aanpassingen of verbeteringen worden gedurende een aantal releases geleidelijk geintroduceerd en en juist de grote aanpassingen willen de ontwikkelaard niet in een enkele release doen om regressies te voorkomen. NIeuwe code betekent ook vaak nieuwe bugs.

LibreOffice zal komend jaar dus een 24.2.y en 24.8.y cycle krijgen omdat er twee keer per jaar een "major" release is in februari en augustus. De 6 weekse patch cyclus voor iedere release zal zoals het nu staat gewoon blijven. Wil je niet de laatste versie van LibreOffice omdat je denk dat die minder stabiel is, kies dan gewoon van de downloadpangina de voorlaatste versie (nu 7.6.x).

[Woopdedooo]

Heeft het niet ook met de continuïteit van een programma te maken?

LibreOffice is eigenlijk altijd een voortzetting, terwijl macOS een harde update is en er vrijwel altijd hardware buiten de boot valt.

[Anoniem: 24916]

Ik heb eerlijk gezegd geen idee OF LibreOffice dit doet of zal doen, maar de 1e grote nieuwe versie is 24.2, of te wel, uitgekomen in februari 2024.
Maar misschien maken ze kleine updates ook wel in de vorm van 24.2.x of zelfs 24.2.x.x.
Een wat grotere update neemt dan het maand nummer mee en als het gewoon een verbetering is van de maand kan versie 24.2 wel tot in augustus doorlopen bijvoorbeeld.

Nogmaals, geen idee of ze dat zo gaan doen.

[sebati]

Patch schema blijf zoals we dat gewend waren, rond de zes weken een patch tot na de volgedende release (24.8). Zie het release schema.

[Simon Weel]

zou meer software moeten doen
Autodesk (van o.a. AutoCAD) doet dat ook - maar dan wel op hun manier. Over een paar maanden komt versie 2025 van de meeste pakketten uit. Je kan natuurlijk het lopende jaar als versienummer gebruiken, maarja, da's wel erg makkelijk, dus laten we volgend jaar gebruiken

Andersom kan ook. Er was eens een bedrijf dat hun OS op een gegevens moment een jaartal gaf. Na een paar jaar besloot fantasienamen te gebruiken om vervolgens weer een gewoon versienummer te hanteren. Maar dan wel met toevoeging van een jaartal + of het de eerste of tweede helft van het jaar op de markt kwam. Ook als er maar 1 versie per jaar verscheen.

[Reactie gewijzigd door Simon Weel op 22 juli 2024 15:27]

[sebati]

Tja, dit krijg je als "de marketing afdeling" zich gaat bemoeien met namen en versie nummering.

[Breezz]

Heb deze software onlangs gedownload omdat ik zocht naar een offline programma om wat te "tekenen" en schetsen op bouwplannen. Deze dat vroeger altijd met Powerpoint of Google Tekeningen. Maar Libreoffice Draw is beter en offline. Het is niet helemaal geweldig maar komt toch in de buurt van wat ik zoek.

[Kargin]

Heb je Gimp (Photoshop) of Inkscape (Illustrator) geprobeerd? Werken ook goed.

[RRRobert]

Paint.NET FTW!

[Mark de Vaal]

Zijn hier .rpm .deb packages van dan?

[bytemaster460]

Het gaat toch niet over Linux?

[Mark de Vaal]

Maar wel over Gimp en Inkscape. Dit zijn mijn main programma's in Linux. Paint.net niet!

[bytemaster460]

Die bestaan ook voor Windows.

[crazyboy01]

Paint.NET voor Linux is Pinta. Niet helemaal, maar het is wel dusdanig een kloon qua functies, interface en zelfs teksten dat als de Paint.NET titel eraan zou hangen dat het gewoon als hetzelfde product gezien zou worden. Overigens is ook Pinta beschikbaar voor Windows, net als de programma's die jij noemt.

[erikmeuk3]

Het is versie 24.2.0.3
De nieuwe nummering is wennen.

https://downloadarchive.d...libreoffice/old/24.2.0.3/

[Reactie gewijzigd door erikmeuk3 op 22 juli 2024 15:27]

[SvMp]

Een van de laatste programma's met normale versienummering. Gaan ze nu ook die onlogische nummering doen met jaartallen

[crazyboy01]

Ik moet bij sommige software soms flink zoeken wanneer een bepaalde versie uitkwam. Helemaal bij oude software die al lang stil ligt is dat soms een opgave die bijna niet te doen is, omdat de changelogs weg zijn en er alleen nog info is over een paar versies. Dan is zoiets wel heel makkelijk aflezen en 0% zoeken meer nodig. En in the end zeggen random versienummers ook niet zoveel voor de eindgebruiker.

Maar, origineel is het niet. En het is wel logischer als ontwikkelaar om met de traditionele versienummering te werken vind ik.

[perlboy]

Op zich is de oplossing simpel: Als gebruikers op zoek gaan naar hoe oud is mijn software gewoon zorgen dat er genoeg informatie in de 'About' dialoog staat:

• Versie
• Uitgifte datum
• Features
• Licentie
• Etc,

Het zou een mooie standaard zijn en er zijn al een heleboel programma's die dit hebben.

[crazyboy01]

Dat is inderdaad het mooist, maar dat is als je de software geïnstalleerd hebt staan. Ik heb talloze oude installers gearchiveerd van programma's die bvb vroeger freeware waren, oude versies met een andere interface/functies etc. Dan is het zonder installatie vaak niet duidelijk, en als we over versies van 20 jaar geleden praten is de info dus vaak ook echt schaars.