Naming conventions

Is there really a need to give the same thing a half dozen different names? Perhaps, depending on who you are and what you’re doing with it.

I’m running /e/ on a Samsung Galaxy S5. It recently updated to “/e/OS 0.14-2021012798470”, which is a catchy title I think.
This release is problematic. I’ve had several spontaneous reboots since installing and now it won’t read the microSD card, even though that card reads fine in a stock Android device. There’s no option available that doesn’t involve reformatting the card and before I do that I’d remove it and use the stock tablet to copy all the information from it, which is ironic to say the least.

So I search for and find a page listing releases.
It turns out there’s a message there about microG and reinstalling it if you were foolishly thinking that you could just apply the update when the system notified you it was ready to do so.
So, how do I fix this?
Well, I need to know what version of /e/ I’m running on the phone. No problem, right? I look in the “System Updater” and get the above information, which is almost, but not quite, useless to me.
So I know I’m running 0.14. That’s the /e/ iteration, or update, of whatever version of Android I’m running. OK, that’s fine. The number appended to it? That’s obviously the date and possibly the time in milliseconds or something that it was compiled. I don’t care. It might be useful information for developers prior to release but it does an end user no good whatsoever and it only serves to sow confusion in userland.

Now to apply the microG fix given on the releases webpage I need to know the version of Android I’m running. Do you think I could get that from the System Updater information? No, I can’t. Since I’m an end user and not a developer I don’t keep track of this sort of detail indefinitely, I just want to put the OS on my phone and use it to make my life easier. To an end user there’s generally little to no observable difference between Android versions. So I have to look elsewhere to find this information.

I go into the System entry in the Settings app and check there. No information about what the system is, or if the information is there it’s buried somewhere.

OK, I go into the About phone entry. Ah, now we’re getting somewhere. It tells me that I’m running Android version 9. Great! Now all I have to do is count my way through the alphabet so I can figure out which version I’m running as listed on the releases webpage and hopefully I choose the correct one. Unless of course they skipped a letter or something. Not being a developer but an end user I have no idea if this is the case. I guess I’ll have to do an internet search instead to find out. I haven’t even discussed stable verus development yet.

Basically, this is a mess. I realize that Guulag gives each release a name, and that’s fine. The same sort of thing happens in the Linux world all the time (Ubuntu for example). But can you try to be consistent with names/numbers in userland? Developers are immersed in what they’re doing and that’s great’; it’s as it should be. Lots of end users are also hackers and they keep abreast of all the new developments so they can sort this stuff out. But there are a lot of end users, and I suspect that’s who /e/ wants to eventually have as the bulk of it’s users, who aren’t in those two categories. Some, like myself, might tinker with their phone a bit from time to time by installing a ready made OS or something, but for the most part just use their phone as a tool. Others don’t even do the tinkering aspect and just want to use it as it was intended for a consumer to use it.

Right now it seems that I need to know the /e/ release, the Android version number and the corresponding Android version name, and whether or not I’m running a development version, which I haven’t figured out yet. Instead of putting a useless date in the version name how about summarizing information that a person actually needs?

/e/OS 0.14-(09-Pie-Stable or Dev or Nightly[date])

It might also be nice to have a link to the relevant page right there on the System Updater screen and also on the About phone screen. That would save a lot of people a lot of time and help keep things organized.

In my past I dealt with clients a lot, and they wanted their projects done. What they wanted, and what I strove to deliver, was a user friendly front-end so that they could easily understand what was being done, when, and how far along it was. If they wanted to drill down on a certain topic I could always get them the details that they wanted, but it was the end user interface that allowed them to decide what to investigate further and what they didn’t have to worry about for the moment.

This is a fundamental requirement for any business that wants to attract and keep customers; develop and maintain an end-user perspective and ensure that the end product is filtered through it. Businesses that ignore this will never grow beyond a niche, and as an example of that for many years Linux end users were almost entirely hackers and enthusiasts.

Perhaps /e/ is still in the development stages and doesn’t see itself as requiring a userland front end. That’s fine. But until it develops a userland front end it will remain as a development project. I’m OK doing the extra legwork required to use a development project when I have to because I want the de-googled aspect that /e/ offers, but the general population won’t be capable of that even if they wanted to because they don’t have the technical background. Current affairs show that this is a time when a project like /e/ should be going mainstream. Thousands of people are being deplatformed and censored by big tech right now and most of them would probably be almost instant customers for something like /e/ if it’s presented properly.

Regain your privacy! Adopt /e/ the unGoogled mobile OS and online servicesphone


… If /e/ works similarly enough across devices (I don’t have a Samsung), you can tap on this (the “Android 9” there), and it will then tell you (among other things) the “/e/ version”, which should pretty much look like what you want to have …

For me it currently says: 0.14-q-2021012698290-dev-FP3.

You’re right, of course. It’s inconsistent across several places in the OS, and missing things here and there, and it’s not good that way.

Hi @Crankey,
The naming convention we are following is the standard practice where the build time gets appended to a device name…the build time will be different for different devices as all builds will not finish at the same time. These are standards in the software industry which we are simply following. The only difference is we add a dev -test - stable to the text to differentiate between the different build types.
The release notes which you have linked is generic and is not referring to a particular device but to all builds made under v0.14 or v0.13 and mentions what is included in that particular build.
You mentioned about different build details in different place on the phone…you can raise a gitlab issue reg this mentioning where you are seeing the differences on the phone. The team can fix this and have the text consistent across the device.

That’s why the build time is not a good criterion at all to compare versions or builds. Why should two different devices not run with exactly the same software version?

Not at all. Many companies use a revision or commit number of their SCMS as last number. This would look like /e/ 0.14.25346 and the last number has two interesting properties: it’s only growing and it’s unique by itself.

Other companies include their release cycles. Microsoft names their products 1809 (means: September 2018) or 2004 which is also a simple, growing and unique number.

I did work in a company where they had three releases per year, a, b and c. The products where named like 2.14.21a followed by .2.14.21b and perhaps 2.15.21c this year and probably 2.15.22a next spring.