> LibreOffice developers are moving to a year.month based versioning system.
The full year might be nicer, but personally I like this idea - it immediately let's you know how old of a version (or its initial feature set, in the case of LTS) you have installed.
For example, in the case of Ubuntu or Unity (the engine) you can tell what you're looking at, at a glance.
> For example, in the case of Ubuntu or Unity (the engine) you can tell what you're looking at, at a glance.
For Ubuntu people often use the codename (including in quite a few UIs, like [1]), something it presumably inherited from Debian, which does the same. I really dislike it, because I usually know which version number I want, but I rarely know which codename I want and always have to look it up on Wikipedia or the like.
The codenaming of the recent Debian releases has been particularly bad, with Debian 10 codenamed "Buster", Debian 11 codenamed "Bullseye", and Debian 12 codenamed "Bookworm".
Not only do they all start with the same letter, but the initial sound is nearly the same, too. It's way too easy to confuse them.
It's not if you don't keep track of releases. "Is Ubuntu codename 2 or 15 years old?" is basically unanswerable. even regular incrementing version numbers are easier: I don't keep track of Debian closely either, but I know "Debian 6" is pretty old, and Debian 12 or so is the latest version.
I predict a future post titled "LibreOffice 3000.01 will succeed LibreOffice 999.12". They'll sure feel silly, having to change the numbering system twice!
And often referred to only by that label, removing the benefit of the yearly naming scheme. Debian is the worst, which doesn’t even have the courtesy to alphabetize their code names.
> And often referred to only by that label, removing the benefit of the yearly naming scheme.
I guess it's nice to have code names, but you still need some sort of a reference to remember what is what and it's the same kind of extra step that you'd have to do with version 1.2.3. Years somehow feel more memorable, at least to me?
Though I've also run into issues with package management. For example, I want to setup a repository that has packages for Ubuntu 20.04 (focal), but I'm using say Linux Mint 20.3 (una) which is based on it locally, because that might be easier to use as a desktop OS (no snaps) or something like it.
Notice how the repository name is constructed dynamically? In that case, something like this might be returned instead locally:
deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu una stable
Whereas what we might have wanted would be more along the lines of:
deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu focal stable
In the example of Linux Mint, I guess them using different codenames sort of makes sense, because their release cadence is a bit different from that of Ubuntu, as are their version numbers: https://linuxmint.com/download_all.php
But at the same time, it's interesting just how much stuff the code names are used for and how things can break. I don't really have a solution, unless we want to have codenames be hierarchical, like bullseye_focal_una to indicate everything - the Debian, Ubuntu and Mint version in the example, and then have more intelligent tools pick the closest thing that exists.
That is something that pisses me off immensely. If you see version 2024.2 you can immediately recognize it is a date, but 24.2 might be a date, might be a numerical version number, who knows.
Ubuntu is the first place I encountered this convention. You might think that Ubuntu 22.04 and 22.10 are closely related because the vast majority of software uses something that loosely resembles semver, but no, they're two different major releases. Very confusing.
Your comment made me look at the history of both Ubuntu and Semver. It looks like the earliest specification of Semver dates to 2011, while the first release of Ubuntu was in 2004. I remember being confused about how to version code until I encountered semver (Ubuntu scheme was the one I used for a short while). It's possible that Canonical was faced with a similar choice and decided to make one up. While schemes like semver did exist before it, they were not so ubiquitous and didn't have a well-defined meaning like semver does.
Major.Minor.Patchlevel was used in the 1980s by the vast majority of Open Source or Free projects. This was a couple of decades old when Ubuntu was first released. The limit between major and minor is blurry, but we did not have to wait for a bunch of people to write a manifesto to use sensible versioning schemes.
> but we did not have to wait for a bunch of people to write a manifesto to use sensible versioning schemes.
That's such a cynical take. The 'manifesto' or the standard is important for two reasons:
1. The scheme wasn't obvious to inexperienced developers. You had to learn it from someone else. Semver standard made it possible for absolute beginners to search and follow the conventions correctly up front.
2. There are a lot of tools that use, support of enforce semver - especially language package managers like cargo, pip and npm. That ecosystem wouldn't exist without the unification provided by the standard.
> That's such a cynical take. The 'manifesto' or the standard is important for two reasons:
I don’t object to the RFC at all. I don’t like it for several reasons, but it has a purpose and it is useful to other people. The points you mention are right. I would just add the caveat that I haven’t seen any real improvement in versioning schemes. Most projects, which were already close, follow it and a bunch of high-profile ones don’t at all, exactly like before.
What irks me a little is the idea that it’s normal for Ubuntu to do its thing because we did not have the concepts behind semver (“I remember being confused about how to version code until I encountered semver (Ubuntu scheme was the one I used for a short while). It's possible that Canonical was faced with a similar choice and decided to make one up”), but please let me know if I misunderstood.
Ubuntu’s scheme was clever and justified, but not because the alternative was mysterious. It was great to new versions being released at a specific point in time rather than when new features or breaking changes were ready. It was also quirky at the time, along with their animal codenames, and it helped them being seen as a new, modern distribution. But GCC, as an example of very high profile free software, has been more or less following semantic versioning principles since the 1980s. And as a teenager learning to code and immersed in the Open Source culture in the late 1990s, I can say that we knew perfectly well what was basically semver without the legalese.
This appears to be a misinterpretation. GP did not say or suggest that any standard or manifesto is pointless, only that it was possible to use good versioning systems prior to their creation.
Fair. But, at least later on, that wasn't universal. There's x.odd for development releases, and x.even for proper releases. GNOME and Linux used to do this.
Also it feels like a lot of projects used to use 0.x numbers, even when they were widely used and stable!
Was going to comment that sem versioning is much older than that, e.g., if I remember correctly version 6 and 7 (early 90s) used semver. Turns out that oracle also switched to year based versioning, thought it was still semver: https://docs.oracle.com/en/database/oracle/oracle-database/1...
I started coding before semver was defined. There was no official name (so nothing to search with) and people had a vague idea about how to do it. That ambiguity meant that everyone did it differently and sometimes completely wrongly. The single name 'semver' and the document attached to it was a silent revolution. So many tools we take for granted (like cargo) are designed around it.
Sort of. For a desktop application, you are right, but for a server application like NextCloud or Jellyfin, semver or something similar can be really nice.
If I'm running ServerTool 2.2.0, and 2.2.1 is available, I immediately know that is a bugfix release and should be minimal to roll out (shouldn't have any breaking changes, data schema changes, etc).
If ServerTool 2.4.0 comes out, that means I probably need to look at the changelog to see if there are any special upgrade instructions or gotchas, however, it is probably pretty safe, and shouldn't have huge changes for users. I wouldn't expect any extensions or integrations to break either.
But if ServerTool 3.0.0 comes out, I definitely am going to test out in in a test instance and validate the upgrade. Any extensions I have probably also need to be upgraded to support the new version, so I may have to wait to deploy it. It probably also has UI/UX changes that affect my users, so there may be training that needs to happen.
Again, it really depends on the tool on what versioning system they should use.
Because writing Windows 11 2022 like any sane man would be far too unreasonable.
No, the H2 doesn't mean anything anymore. Once upon a time it stood for "Half", with H1 standing for "First Half" and H2 for "Second Half" of whatever year in two digits.
Of course, I still find this nonsense far more preferable to the bullshit that is the Chrome Version System where the entire number means jack shit.
Using a datecode shows immediately how old a given release is, which is useful information. I don't know how old Chrome 101 or Firefox 89 is; I know how old Windows 11 22H2 or LibreOffice 24.2 is.
Using a traditional Major.Minor.Revision.Build version number shows how much of the codebase is common between different versions. I can expect something made for one Major version to work in any other same Major version release, I can expect only a Revision or Build increment to include only very minor changes; likewise I can expect breaking changes between different Major versions. I don't know what Chrome 101 is other than it's after Chrome 100; I know NT6.0, 6.1, 6.2, and 6.3 are largely interchangable.
For an end user product like Chrome or Firefox, the version number does not matter as much, it's really only useful for developers who might depend on specific versions.
This time and age I don’t believe anyone really depends on specific version of browser.
You could pull that maybe for a month. Longer than that and your customers will drag you through hot coals that you fix your stuff and move forward because you block security updates they need to install.
Unless of course you have it somewhere deep in company and it is IE8 app that no one can update.
But if you do anything public or SaaS platform you probably just fix stuff to support new versions or you are out of the game.
MS start using H1/H2 for version since 20H2. An assumption is that "2009" is confusing or causes compatibility issue with older Windows release (Embedded 2009).
and then completely disregarding that version number that is shown easily to you, and making you remember which animal adjective matches to it when you want to download any file.
I like libreoffice for what it has represented since the days of StarOffice. BUT...
A couple of months ago my dad and I had to edit a large-ish book of 250+ pages (recipes) with a Table of contents and whatnot.
We ended up using Google docs because LO TOC and headers sync and editing Functionality was lacking.
I remember in MS Office 2000 there was a view showing only headers and easily allowing you to correct levels and indentations, as well as moving full sections.
Also we needed to automate a bit some image formatting and G docs scripting was just more straightforward.
And finally, the seamless online collaboration made it a no brainer, instead of document sharing and changes tracking.
It's a shame LO has achieved a lot and is amazing we can have such functionality for free. The team has done an amazing. I was just bummed something like GDocs seemed more complete for my book use case (particularly bc editing a 250+pages book in the browser is PAINFUL)
Interesting, as I have had the opposite experience. There are lots of documents that I have to work with -- most created originally in Word 2007, I think -- with very intense formatting, forms, embedded charts and other crap, and Google Docs makes a total hash out of them.
LibreOffice, OTOH, pretty much looks just like they did on the original.
The one issue I've run into is font substitution. The fonts that LibreOffice uses by default if the actual Microsoft fonts aren't installed are not, at least IMO, very good substitutes. They don't look great to me, but worse they seem to be very different in terms of character/word width, so everything gets reflowed to hell and back. But assuming you install the actual MS fonts, the results seem quite good.
YMMV - I just cursed LibreOffice a few minutes ago while trying to open and fill in a form (amateurishly) built in Word. When loading it, it obviously didn't look as it was intended (text boxes were overlapping and partly obscuring each other), but it was more or less Ok. But after filling it in, it wasn't able to print it - the print preview only showed an empty box! I then proceeded to upload it to Google Docs, which also didn't show it as intended, but at least managed to print it.
Yeah, I already politely suggested to the people who sent me that document to use PDF instead (just in case they were wondering why the document they received back looked different from the one they sent). Nevertheless, LibreOffice claims to support this document format, so users will complain if the support is not up to scratch...
Yes, the overlapping boxes might be because of a missing font, but for me the kicker was that the document looked completely different (with most of the text missing) in the print preview - not to mention that it was spread over two pages, although it fit on a single page while being edited.
I understand your sentiment and I also cry a bit inside when I see people install OpenOffice because it has the brand identity. However, it has a right to live even as a bit of a zombie.
IT degenerated into a dreadful tribalism virtually from day 1 - ooh my BBC B is so much more beige than your Commodore 64, which is strangely brown. My ZX80 is so worryingly ... rubbish than your errr ... oh well the Z80 runs washing machines really well!
My uncle used punch cards to do programming at university (I'm 53 and he's older). There was a debate about the best clipper thingy tool to use. All they have to do is make a rectangular hole in thin card accurately. It was a precursor to vi vs emacs etc.
OO has a right to live on if there are still users and developers. A monoculture is awful. Do you recall or at least know about IE6? We are also seeing the same thing unfolding yet again with the Cr browsers. Not for me thank you.
Just to bing things back into the real world: In the UK there are several first class spoken languages: English, Scottish, Welsh and Irish. The Brythonic (literally: British) languages suffered dreadfully but have bounced back somewhat. Cornish is starting to show green shoots and Cumbric might be resurrected in some form. There are some others too. These are the languages from before the Romans and the Angles and Saxons made a few changes hereabouts. I think they are incredibly important and without them, the UK would be severely impoverished. That's just the locally grown languages, I should also shout out to the vast number of languages that have rocked up on these shores and enriched the place, from all corners of the world. Its not a one way thing: the welsh word for microwave is often: "popty ping" - see https://welearnwelsh.com/words/welsh-word-for-microwave-popt... for a better discussion
I hope that OO does get get up and have a crack. We could do with some more diversity. I refuse to denigrate someone else's project - I'm not doing anything better.
I don't think it's a fair comparison. OpenOffice sees no meaningful development, and it still has the brand recognition, causing people to mistakenly install it thinking it's basically libreoffice, i.e. actively maintained software. Instead, it's just a snapshot of an ancient version of it, giving people the false impression that the project is dead in its tracks.
Just as a note since it’s not 100% clear which project you’re talking about, LibreOffice and OpenOffice are now two different projects. One is just a fork of the other.
LibreOffice (the topic of this article and version change) isn’t very sad imo!
I interpreted this as "LibreOffice supplanted OpenOffice so completely and so long ago that OpenOffice should just give up." (Not up to date with what or how the OpenOffice project is doing these days so I have no opinion on them personally, I always thought LibreOffice was essentially just a re-brand though?)
OpenOffice only gets enough bug fixes to keep it running but it hasn't seen a serious feature added in a decade. It's dead. Oracle screwed up the governance of OpenOffice and basically forced the fork by not accepting major features for political reasons.
When everyone jumped to LibreOffice, rather then handing it over to LibreOffice, they let it to go live on a farm where all big projects go to die: The Apache Foundation.
The upside is they did assign everything including patents and trademarks to the Apache project though and relicensed everything under Apache's license where LibreOffice is still LGPLv3/Mozilla Public License (MPL) from back when it forked.
What's with the Apache Foundation being the literal farm where projects are sent to die? Over the years I've come to associate any of their project with "it's basically abandonware, avoid" which has also coloured my opinion of the Apache web server, which was very much alive at the time. In fact, these days even the Apache server project has gone silent and virtually dead to most [1], except for those that still run the classic LAMP stack.
So, why has the Apache Foundation basically become synonymous with final resting place for everything under their stewardship?
1: fun fact, Apache ran 50% of websites in 2009, by 2022 this share fell below 25%.
There are many vibrant projects under the Apache Foundation that aren't the web server or other handed off projects, Superset[1] and Solr[2] being the two I am familiar with.
There are plenty more. Log4j, Maven, Zookeeper aren't dead. Not sure about Mesos but I was given a book on it a few years back as part of... the SMACK stack I think?
I wouldn't be so sure. Yes, 25% is higher than I expected, but there are a huge number of sites that haven't been updated since 2009. A lot of the Internet runs on a LAMP stack installed on some Ubuntu 15 years ago and never upgraded or patched since.
But very few of us are starting new projects based on Apache. Even when I have to deploy PHP for clients I usually go for stuff like Caddy which is built for the 2020s and and entire Wordpress config, boilerplate included, is less than 30 lines.
> What's with the Apache Foundation being the literal farm where projects are sent to die?
I think it's because they accept so many project, but people misunderstand what the Apache Foundation does. Companies and researchers often seem to have the idea that they can just throw their code over the fence and Apache will have a team of developers ready to pick their stuff up.
All the successful Apache projects are those where the developers just need hosting, guidance and perhaps legal assistance, but they themselves stay on as the developers.
Apache shouldn't have accepted OpenOffice, but perhaps they where affair that we'd be left without an office suite.
> they let it to go live on a farm where all big projects go to die: The Apache Foundation.
There is another similar farm nearby named the Eclipse Foundation. Well, just like Apache, they have some projects which are very much alive; but, just as Oracle sent OpenOffice off to Apache's pastures, they similarly sent Hudson off to Eclipse's. Unlike OpenOffice, Hudson has already shuffled off to the great beyond; OpenOffice still clings to life, if barely.
OpenOffice was owned by Sun Microsystems and transferred over to Oracle. Most of the devs working on it weren't satisified with how the two handled the project and left to form The Document Foundation, which forked it into LibreOffice.
Shortly after, Oracle killed it completely and fired the remaining staff, however IBM convinced Apache to take it over and re-release it under a more permissive license. Now, OpenOffice is basically a zombie of a project that refuses to die and hasn't seen any new feature upgrades since 2014, while LibreOffice releases ~2 feature upgrades every year.
But it's not completely dead. It does receive some bug fixes and security patches from time to time.
Apparently there was also some footdragging by Sun (because Sun) and later Oracle (because evil) about creating a neutral caretaker foundation to guide development.
Circa 2010/11, the development community decided to do it themselves.
OpenOffice is limping along, about a gazillion commits and bugfixes behing LibreOffice. To match your Internet Explorer 6 experience, try OpenOffice today!
A long time ago, there was a free-as-in-software office productivity suite called "OpenOffice.org" yes, that awkward name was how it was branded. This isn't how it started, but it's how it was at a certain point years ago when our story begins.
OpenOffice.org was owned by Sun, who had purchased StarOffice for their internal use and, since it was the trend at the time, decided to Open Source it, creating OpenOffice.org. At first it was under a weird Sun license, but eventually Sun LGPL'd it.
Working with Sun was very annoying, but it got much worse once Oracle bought them in 2010. Officially Oracle continued to support OpenOffice, now "Oracle OpenOffice" but a lot of non-Sun people who worked on OpenOffice.org eventually formed The Document Foundation, which still exist todays and produces LibreOffice. Most third party work on the software moved to TDF and thus LibreOffice.
But, Oracle still owned the OpenOffice name, and with it the brand awareness. They could give this to TDF, but how does that enrich Larry? It doesn't. So, they "gave" the project, branding and source code (including code which wasn't yet LGPL'd) to the Apache Foundation. You can go back and look at the public comments on this "adoption" and see that, very unusually, there is strong opposition to Apache taking this, and thus enabling what is clearly a nasty outcome for end users.
Apache's board members bizarrely claim not to remember any such reaction (publicly recorded in their own archives) and say they believed that this was a strong, successful community, which is weird because again their own records show they repeatedly had problems with its "leadership" which were engineers now employed by IBM, basically to work on an IBM project that re-used this source (hence not being keen on LGPL) from Oracle. So for a few years you have a situation where there's an abusive jerk who is "Vice President" of Apache OpenOffice, the Apache management pretend not to notice, and instead are incensed that the TDF people seem to think this is Apache's fault...
And then IBM loses interest and so "Apache OpenOffice" is dead. But Apache aren't willing to throw in the towel, that would be too much like admitting everybody else was correct years ago. So it carries on as a zombie. In early September 2016 (ie Seven Years Ago) I wrote this about the prospects for the project:
""If in say, three months, there's no measurable evidence that AOO is back on course then regardless of what is said by the handful of AOO people, retirement is the right choice.
For example, shipping AOO 4.2 in 10 weeks at ApacheConEU. That's not crazy. Libreoffice goes from feature freeze to release in 10 weeks. A healthy AOO development community should be able to do it, or come so close as to leave no-one in any doubt.""
What happened to AOO 4.2 ? Did they ship it in 10 weeks at ApacheConEU ? No they did not.
OK, but how late was it? It has never shipped. In the subsequent seven years AOO has never shipped a feature release, just small bug fixes for their already outdated software. For a while they used to speculate that they'd release it "next year" but they eventually gave up even pretending. It's dead, it's just a zombie project, the main thing the remaining "project members" can be bothered to put effort into is denying that it's dead. Anybody who writes actual software is working with TDF.
It would still be interesting to know whether there's some larger reason Apache agreed to help Oracle do this. Did the Foundation get paid? Did its board? But in practical terms Apache is indeed where things go to die and OpenOffice helped seal that reputation.
Draw is a super underappreciated piece of software imo. It's not quite Publisher, not quite Inkskape, but something in between. I'm not sure what people use it for, but I used it in college to make diagrams for all sorts of projects. LibreOffice's equation input is great, too.
My preferred Open-Source-Software for diagrams is draw.io (https://app.diagrams.net/). Works great, locally and online and runs on pretty much any system while offering everything I need and allowing a crazy amount of customisation.
I'd describe Draw's page handling as "intuitive," if not "sophisticated." You won't get Inkscape's most powerful features, but MS Office-like "stupid simplicity" is the result.
LibreOffice has pretty cool support for working with PDFs in general. (Tangential) There's a "hybrid PDF" export option in LibreOffice that lets you embed ODF metadata into the PDF file. When you open the exported file in LibreOffice again you get everything back -- dynamic fields, header/footers, custom style sets, etc.
When the whole discussion of "libreoffice for personal use" came up, I found out that the foundation, libreoffice foundation DOES NOT HIRE DEVELOPERS. Due to some stupid German laws, that would equate to competing with for profit orgs.
Any donation you do to foundation is for "conferences and stickers".
There are only free volunteer developers and paid orgs like collabora.
However, out of 16 The Document Foundation employees/contractors, I count 9 (including myself, Ilmari Lauhakangas) who do at least some LibreOffice development or 11, if you count development outside of LibreOffice source itself. So donations have always paid for development as well.
cool. that is, as i said, from the discussion from last year i think.
i regularly submit bug reports and have something like 20-25 open issues that i have submitted.
its nice that 11 people are doing dev work but don't you think we should be doing more? wouldn't it be possible to get a grant from wikimedia for doing dev work directly under foundation rather than from collabora et al? wikimedia certainly has the money to bankroll LO.
that said, 11 people are not a lot considering the scope of the project.
why doesn't the foundation use cheap labour from other countries? you can certainly have 5 FTE at the cost of a single american/german one? india for example. There is a lot of indian/indonesian communties. these volunteers would love to be paid to fix things.
The foundation was set up to foster an ecosystem of commercial companies (or in-house teams in public sector entities) and that is the emphasis that the directors of the foundation have maintained since 2010. While I agree with you that there is space for the foundation to do more in-house without stepping on the toes of the ecosystem companies, it was not a walk in the park to get approval for the hiring of two C++-focused devs.
LibreOffice contributors can influence how the foundation operates by becoming members of the foundation and voting in director elections or becoming elected into the board of directors.
I am mentoring over 120 new volunteer contributors per year (most into C++ development or quality assurance). I'm really happy with the workflow I've constructed and you can read more about it here: https://discourse.sustainoss.org/t/how-i-recruit-and-mentor-...
As TDF is a non-profit, cost of labour is certainly an important factor when hiring.
the foundation gets a x amount of donation. they can spend 100% of that for anything in their bylaws. paying for devs, conferences, paying freelancers to fix bugs. They wouldn't have to pay income tax if they spent 85% of the income during the year so the incentive would be to spend almost all of the funds received.
Interesting, I used to use word processor that aren't cloud based, but many years ago I've lost to many of my writings due to crashes or power loses, do that when I finally discovered cloud based word processors it was like magic to me, because it didn't crash and if I lost power I didn't lose any of my work!
Save for rare cases, I'm really content with the Apple apps: Pages, Numbers, Keynote. And I love the Apple document management. Document always saved and versioned.
If I had to go back to Linux, and if it were an option (which it’s not), I’d pay $300 without hesitation, to have all Apple’s office-like and other “bonus” apps on it. They’re my top choice in practically every category, when outside factors aren’t deciding for me (it’s usually MS or Google crap, when that happens—man, I hate Google Docs)
LibreOffice (and MS Office) have had automatic saving for several years now. If the program crashes or your PC loses power or whatever you won't be losing your work.
I use it all the time, not because I'm as good as I'd like to be about keeping things out of the cloud that don't need to be there, but because I often have ad hoc spreadsheets that are bigger than Google Sheets can handle.
Yes because I dont like clouds. But I truly dislike any second I have LibreOffice open. It feels slow, clunky, ugly, non-native on Linux and it is generally not a fun, stable nor feature full enough piece of software for a very light user like myself.
I mean, I chose to learn LaTeX rather than having to put up with LO for a simple rich text document.
The sad thing is that the other non-Office alternatives are even worse in their own way. Word processors are like browsers, huge, complex, requiring a ton of compatibility subsystems, yet without the massive corporate backing actual browsers have. So there's only Microsoft, and a lot of small players that would have to spend literal billions to reach 50% of the power and polish of Office. Word processors are basically living fossils, relics of a bygone era.
It's sad, really, because people still need to write documents and spreadsheet, but no sane company will seriously try to enter this space ever again.
I use Calc every week and it is snappy enough and hasn't crashed in a decade+. More features than I could ever use. Sounds like you're exaggerating or need a Pentium overdrive.
Last I tried desktop Excel on my 20 core machine, it felt much snappier than Calc ever did. Shame on me for expecting a spreadsheet app to run as melted butter on a i9 10900k.
To be fair, the word processor is the one that has annoying writing latency. My issue with Calc it is clunky to use, and not very HiDPI friendly.
Core eye five here... never have had to wait for input. Takes a second or so to start. Any better and I wouldn't be able to perceive it.
No HiDPI problems, perhaps a new icon theme?
I'm sure Excel is better on many metrics due to investment, and if you are a spreadsheet-jockey that last 5% really matters. But, neither a factor here.
The typing latency is the worse I have experienced in any Electron app. As much as I would like to use it, LibreOffice on that front is snappier, and not even by much.
I install it on my mom's laptop, and, after configuring it to save to Microsoft formats by default, it works great for everything she uses it for (personal documents, various things for church and other groups). for her purposes, it's worth it to not have to pay the now-annual Office costs.
Occasional spreadsheet user. Was using a well-known proprietary software until now but LibreOffice's interface is much easier to use for me. I don't have to keep looking again for the place each option is. Especially, in Writer, all text formatting options are in a single place so I never have to spend much time looking to find a given feature.
Bonus point: pressing Ctrl-S actually opens the file save dialog.
I still use it for some things here and there, but most of the time when I want to write a document or spreadsheet, I either a) want to share it with other people, or b) keep it private, but be able to access it from more than one device. So, Google Docs it is, unfortunately.
Of course you'll find countless HN users who use it or have set their family up with it, but in general, no, I don't think many people want locally managed files anymore. The whole point of documents is to share them, and cloud offerings do that better.
The whole landscape has shifted from underneath LO and I'm not sure they have the capacity to adapt. Especially since they still haven't made a decision about what the toolbar UI should be, something that should have been settled a decade ago.
I still use google docs for my own spreadsheets because it’s just a better tool, and it keeps my files available on every device.
The toolbar UI story is that MS added the ribbon UI in 2007 and LO finally added it in but didn’t turn it on, they now have a settings page with multiple toolbar versions you can pick from for some reason. Meanwhile the ribbon is now obsolete before LO even utilised it.
Take a look at how dreadful the LO toolbar is. Hundreds of random icons for things you couldn’t even name. Compared to google docs where every icon on the toolbar is identifiable and useful.
Sure, share the documents, but running apps over the net - ha!
I despise every time I open an MS Doc or gmail. Just now gmail loaded almost 13MB of "app" - just to show an almost empty inbox, what a waste! And (behind the scenes) it's still loading stuff after almost 30 secs.
Cloud apps are the IT version of supersizing. Morgan Spurlock showed what happens when you use capacity just because it's available - obesity.
You might have an unusually slow setup. For me on an average computer and internet, gmail and google docs loads instantly.
Only web app I had an issue with was Adobe XD which would load the whole 700mb project file on every page load. Though I think we were pushing the program beyond it’s designed use case.
Anecdotally, it's been a very long time since I've seen an actual document sent to me. Across multiple companies, it's always been an office or google docs link.
There are close to no compelling reasons for a company to email document attachments around these days.
Really? Because I'm still being sent documents frequently by a lot of people. And the number of PDFs I get sent that are originally Word documents is huge.
I never used office software much, but I do use it to view the occasional csv. I avoid cloud offerings like the plague, since I don't like getting rug-pulled.
Google Docs has RE2 support. However, Google Docs is so laughably bad in other features compared to LibreOffice and MS Office that I can't recommend it with a straight face for any but the most basic use cases.
Exporting to .xls files it's pretty bad, so it's a no for sharing. Unfortunately, Google sheets does a better job here. I assume cloud office is the best in this case but haven't tried it.
Ironically, if one uses the export feature from G-docs they actually use LibreOffice under the covers (I'd guess Xvnc or similar); I found this snippet hiding in a g-doc export, so it's entirely possible they use something different for .xls exports
I switched from gsuite to LO a while back for the vast majority of my personal documents. TBH I miss some of Sheets, but on balance I prefer having less of my data in cloud providers' hands.
I use it frequently for editing csv files. It's also a great default to have on Windows computers that need to open the occasional Word document. It fixes some of excel's mistakes, too, especially the one where opening a csv in Excel now doesn't bring up the text import wizard.
I also love the plug-ins that people can write in Python or whatever suits them.
The database is for the birds, and I haven't gotten any use out of the other parts.
I tried LibreOffice for the first time in many years recently to help me generate some nice templates for ODT documents I wanted to export using Emacs' Org-Mode. Overall I was really quite impressed with how far it has come.
I also found that ODT documents also import nicely from Google Drive into Google Docs, which is a great way to get feedback on documents I author in Org-Mode with my teammates.
Primary office program since a decade or so. I don't own MS Office and for many purpose it is quite convenient to have/be able to use files on disk (admin forms, attachments and downloads, etc). I use cloud tools when needed but I am very happy with LibreOffice otherwise.
I mostly use it to view files so that I don't have to re-upload them to Google Drive just to open them in Google Docs or Sheets. If LibreOffice could work directly from NextCloud, I might be inclined to intentionally use it more often.
I use both. I use local for stuff I consider important (estate documents, financial documents, etc) and the "cloud" when I don't care about the risk of storing information on someone else's computer.
Since recency and scale of difference are the two most important factors, why not use a combination of date and marketing" major/minor version instead of opting into either one of the other?
Yeah, because rationalistic, non-populistic Spaniards don't ever exis...
Oh wait, their main novel which might be the most important novel ever, (at least for the spark of modern times) it's a fight between idealism and materialism making fun on the old farts!!!
So, who knows, Libreoffice for everything else means an office without ties to Microsoft and any corporation making your yearly profits slave of what Microsoft thinks on their licenses for your desktops.
They should really follow MS and go web on this. Have a local electron app for offline users but have the same code base for self-hosted cloud or their own paid/supported cloud office offering.
There are several well-heeled competitors in that space. Do we need another one? You really want to pay hosting for word processing? Or pay with your privacy instead? Electron—big no thank you there as well.
That said, I think someone is looking into it. Choice is fine, as long as this local app continues.
So long as the local app has the same features. It is like a decade behind constantly right now. I figured web based is easer to contribute to so we get open source and good features. Self hosting for wp on the same machine is not a big deal or for a family/smb
Free with premium features doesn't really work economically. Or you could pay a L.O. dev to add them instead of sending money to the cloud?
Personally, a decade behind is ok with me... I was happy with Office '97, and was actually fine with the earlier ones, but that is the first I remember that were 32-bit.
The only thing I wanted for a friend was "outline mode" in the word processor, and I think it has finally been implemented.
That's not what I said though, paid support and paying them to host and manage it for you is not paid features. The features remain the same.
I tried to use it but the few times i personally needed it, it was to edit resumes and other formal stuff for people who need it in docx format and the result looked very unpleasing. Vice versa too, opening documents others send from the latest O365 is a pain.
Should never send a resume in doc format. They ask for it so they can edit it behind your back. Used to be .pdf was for that and LO supports it nicely.
However, pdfs are trivially edited today as well. Perhaps need to start sending with a hash or using code signing!
Clickbait title but makes sense. Yearly versioning.
Edit: -4. Touchy HN lately. You can diss Unix with toxicity but suggesting a clearly clickbait (hide the actual summarizing headline in favor of "you will be surprised by this big change") is a big no-no.
How is the title 'clickbait'? Calling It "LibreOffice Changing To Year.Month Based Versioning Scheme" or similar just makes it longer and less immediately clear... Really I honestly fail to see how it could be considered 'clickbait' for phrasing it as simply as possible.
The title is definitely supposed to play on the shock factor of 24 clearly not being immediately greater than 8, and possibly the mixed reactions to some other software moving away from SemVer (Firefox switching to Chrome's scheme comes to mind)
It wasn't immediately apparent to me that the new versioning scheme would be year.month/whatever, which is the real news, but it's less interesting.
> How is the title 'clickbait'? Calling It "LibreOffice Changing To Year.Month Based Versioning Scheme" or similar just makes it longer and less immediately clear... Really I honestly fail to see how it could be considered 'clickbait' for phrasing it as simply as possible.
"LibreOffice Changing To Year.Month Based Versioning Scheme" is far more clear than "LibreOffice 24.2 Will Succeed LibreOffice 7.6". The only reason I clicked through to the comments is because it was not immediately clear to me why LibreOffice would choose to skip to 24.2.
I don't think semver is very useful for applications as opposed to libraries.
Remove some obscure feature which almost nobody ever used? Backward incompatible change, must increment major version.
Add some major new feature which is a massive quantity of code, visible and likely important to all users–but 100% backward compatible? Increment minor version instead.
Makes sense to (some) developers, but to an end-user semver is rather nonsensical. Everyone can understand calendar-based versioning.
> Everyone can understand calendar-based versioning.
Yes because it does not any meaning. Earlier major versions were reserved for adding new features, but since CADT took over the world, they just mean another version which has nothing to do with the old one.
If the year is 2023 and I am running WhateverApp 2010, I instantly know I am running a 13 year old version, and it is probably a good idea to see if there is a newer one-even if I’m completely happy with the 2010 version. Decent chance of new features, some of which I might find valuable; also, with every passing year, the risk of interoperability/compatibility problems (with file formats, new OS versions or versions of other applications)-even if I haven’t hit any of those problems yet
Whereas, if the year is 2023 and I’m running WhateverApp 2021, that’s only a two year-old version, so absent any specific problem or missing desired feature, looking for a newer version is going to be a lower priority
Calendar-based versioning gives a good sense of how old a version is. As an end user of LibreOffice this does a better job of helping me stay up to date, and tells me a lot more than semver - what is even the “public API” of a GUI app?
Semver in applications tells you important things such as how different a release is and how much incompatibility to expect. "Public API" doesn't really enter into it, but it's certainly useful to know at a glance how different the release is from the prior release.
Calendar-based versioning gives you no hint of any of that. It's important to know because if it's a minor release, I'll want upgrade to it right away. If it's a
bugfix release, I'll want to upgrade urgently. If there are major changes, I'll want to put it off until I have time to handle the disruption. If I have to look up how large the changes are, I'll just assume every release represents a major change and will put off upgrading until I have time to deal with it.
True, semver doesn't literally tell you how old a release is, but how often is that important? What you really want to know is whether a release is newer than the one you have, and semver does tell you that.
> Semver in applications tells you important things such as how different a release is and how much incompatibility to expect
I disagree that it tells you either.
Release A adds massive new features, with hundreds of thousands of lines of new code, dozens of new third-party dependencies, but with zero (intentional) backward incompatibilities – increment minor version only.
Release B only removes one tiny obscure legacy feature which almost nobody used. But that's backward incompatible, so must increment the major version.
For any user considering whether to upgrade, release A is almost surely a much bigger risk than release B – yet semver tells them that B is major whereas A is only minor.
Similarly, consider release C which removes dozens of features, many of which are widely used. Obviously release C is a much bigger risk than release B which only removes a single obscure legacy feature – but since semver treats backward compatibility as a binary "yes-no", it fails to communicate that release C is a much bigger deal than release B.
> True, semver doesn't literally tell you how old a release is, but how often is that important?
Well, if the year is 2023, and I'm running WhateverApp 2010, I instantly know I'm running a really old version, and ought to look into whether there is a newer one. Whereas, if I'm running WhateverApp 2021, it is only two years old, so I'll put researching newer versions a lot further down my priority list.
As far as I'm concerned, replacing a feature with a similar one (major version bump in semver) and adding a new feature (minor version bump in semver) are pretty much completely equivalent to me. Adding a new button for a purely-new feature is a "breaking change" - that is, if it's in some keyboard-navigable menu, I now lose muscle memory on how many 'down' presses it takes to reach it (or, in a GUI, the entire layout might have changed to fit the new button), which is about as annoying as being forced to use a new workflow due to a replaced/removed feature (assuming I ever used it).
So semver for GUIs is just entirely useless to me. Whereas a calendar-date actually gives useful information:
- if I desire some obviously-desirable feature, how likely is it that the newest version might have it (semver even de-emphasizes this via making additions minor bumps!)
- whether it's worth bothering to report a bug (devs likely won't care about problems in years-old versions, but 10 semver major bumps could be anywhere between decades and weeks old, depending on how the developers chose to define "breaking change")
- whether the version is representative of the up-to-date state (for semver you could maybe determine this if you looked up the up-to-date version number (already a big ask) and subtracted, but again that'll primarily only tell you about amount of removed stuff (and not even amount!! just the number of batches! you could have 10 major bumps have less removed stuff in total that one major bump), not added stuff)
- whether whatever package manager gave me a reasonably-up-to-date version
You're not describing semver, you're describing traditional feature-based versioning, which I agree is nice.
This is semver:
> Remove some obscure feature which almost nobody ever used? Backward incompatible change, must increment major version.
> Add some major new feature which is a massive quantity of code, visible and likely important to all users–but 100% backward compatible? Increment minor version instead.
There are many, many modules that make up LibreOffice. At what point do you think they should update the major version?
It doesn't work for an app like LibreOffice. For a library with well defined interfaces, it does make sense as you can easily find breaking changes. LibreOffice shouldn't be making these sort of breaking changes. The libraries that under LO are using proper semversioning.
As a personal user of calender versioning, it solves some of my problems with sematic versioning, telling when it was released at a glance, and it makes it easier to apply; just look at the date, making it 0-1 clicks. Sematic versioning, on the other hand requires you to remember the last version, and apply accordingly, which takes 1-3 clicks for me.
SemVer is more useful in Apps if you use feeling vs strict rules. A massive UI overhaul (but without breaking features) is almost definitely a major version bump but SemVer says it's a significant minor jump (5.0->5.5), at best.
The problem is that SemVer was released for libraries, where it's rationale and rules make sense. But the abstract spirit of major.minor.patch makes more sense at an application level.
If apps followed SemVer properly they should be bumping the major version for most UI changes (let alone overhauls), as they all break user workflows. If a button moves, you need to learn the new location. Shortcut changes? Tough luck, your muscle memory just deleted the last hour's progress.
I don't think that's useful for users though. It's best to assume that any upgrade will break something for you, so maybe optimize for new features and bug fixes (if you even need any). Which is where other version schemes can be more helpful as they can give a greater scope of the number of changes (e.g CalVer tells you how out to date you are).
> If apps followed SemVer properly they should be bumping the major version for most UI changes (let alone overhauls), as they all break user workflows.
This is just reiterating my entire point. People follow the rule/strict interpretation of the law and SemVer breaks, you should be following the spirit of the law.
I didn't exactly intend to disagree with you, but I did get a bit combative there though, as I narrowed in a bit much when writing my response. I wanted to expand (and work out my thoughts) on
> A massive UI overhaul (but without breaking features) is almost definitely a major version bump
as I think effect of UI changes tends to be underestimated. Just because v1 & v2 both have a button to frobnicate doesn't mean that they are equal. If v1 had a big large frobnicator in the main screen, and v2 buried it in a menu, you could say that no feature was broken, but the user interaction is very different.
That sort of change often gets rolled into a minor/patch bump, but it does break workflows. However if every change like that bumped the major version, it would be noise. There would be no way to judge the scale of the changes from v9 to v23 vs v14 to v16.
I'm not sure if the spirit of the law of SemVer applies here though. The type of change is not important, only how much has changed. Bugs can be features.
Calendar versioning makes way more sense for end user applications, especially those with GUIs. There isn't much concept of a non-backwards breaking change in something like libreoffice, so semver ends up trying to expose information that isn't there.
Semantic versions only make sense if you anticipate discontinuous breaking changes in the future, with periods of stability between. If no new version will be a breaking change, or if every new version will be breaking, it loses meaning and you might as well go date-based. (Or, if you're Linus Torvalds, completely arbitrary.)
Part of my point is, if the software doesn't have a concept of "breaking change" semantic versioning makes no sense, so you might as well just use numbers that change with every release so you can easily refer to when bugs got fixed or, maybe, features got added.
Applications do have the equivalent of breaking change, though. Sometimes literally in the sense that file formats change, but more usually in the sense of having to relearn how to do things, or the removal of features.
lol. "Breaking change: all English text is rendered right to left now. In can be changed to bottom to top in the compile options. Left to right has been removed."
The full year might be nicer, but personally I like this idea - it immediately let's you know how old of a version (or its initial feature set, in the case of LTS) you have installed.
For example, in the case of Ubuntu or Unity (the engine) you can tell what you're looking at, at a glance.