Epyrus version number handling: Any one have thoughts on it?

Board for discussions around the Epyrus mail and news client.

Moderator: athenian200

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 892
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Epyrus version number handling: Any one have thoughts on it?

Unread post by athenian200 » 2022-09-28, 23:44

So, early in development I decided to just use MOZ_APP_VERSION set to 52.6 along with Thunderbird's GUID so that all the existing extensions would work, but then used MOZ_APP_VERSION_DISPLAY as my Epyrus version. The main thing is that I wanted my version number to reflect my development and not Mozilla's, but I also wanted extensions to "just work." I figured that if I'm not using the updater anyway, it doesn't matter if the version number is the real one or not. The appeal at the time was it was a quick fix that achieved pretty much what I wanted, and didn't require me to dirty up UXP with a bunch of Epyrus-specific ifdefs.

I've actually been renaming the packages the build system generates manually to match the Epyrus version, and just kinda making it work.

What I'm finding is that to go forward with this approach, I would end up putting a lot of ifdefs in UXP anyway... it's not technically difficult, but it's just reaching the point where I am wondering if it's the right thing to do in the first place, since I'm finding it adds up to almost as many changes as the dual-GUID approach, just in different places. Basically, instead of having ifdefs that modify all the places where an extension checks the version number, I would be using ifdefs modifying how the version number string is passed down and checked in other places, like for the user agent, the packager, the updater, troubleshooting information, etc. Basically, all the places that present a version number to the user but don't affect extension compatibility.

Ultimately, the idea is that extensions can continue pretending Epyrus is Thunderbird 52.6 until kingdom come, and users can just know the real version number in relation to my development.

I guess what I'm wondering is, is this actually a good approach for Epyrus going forwards? The only potential downside I can think of to doing things this way is that maybe it would make it harder for extensions to target Epyrus in the future if they wanted to, but I'm not sure how big a deal that would actually be if extensions also have their own version numbers and newer versions should generally target the latest Epyrus anyway.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
moonbat
Knows the dark side
Knows the dark side
Posts: 4161
Joined: 2015-12-09, 15:45
Contact:

Re: Epyrus version number handling: Any one have thoughts on it?

Unread post by moonbat » 2022-09-29, 02:47

Can you set it to use 52.6.xxxx where the last 4 digits reflect your own versioning? Maybe that would help with extensions looking for that version as well.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."

Image
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 892
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Epyrus version number handling: Any one have thoughts on it?

Unread post by athenian200 » 2022-09-29, 03:04

moonbat wrote:
2022-09-29, 02:47
Can you set it to use 52.6.xxxx where the last 4 digits reflect your own versioning? Maybe that would help with extensions looking for that version as well.
Well, I am free to bump the MOZ_APP_VERSION number at any time. I might just wind up bumping it only when I make a change that could affect extension compatibility. That way if I release a new version and nothing I did is going to affect extension compatibility, I can just leave it alone, whereas when something like that does happen, I can bump the version. I have doubts it's going to be a major issue, though. Or, I could even implement a way for the few extensions targeting Epyrus to check the "real" version number using a different field than "version," if it ever comes up.

But overall, I really don't want the 52.6 in the version number I use for my own development, and I really want it to be clear that the number extensions are targeting is completely arbitrary and has nothing to do with Epyrus's overall development.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
FranklinDM
Add-ons Team
Add-ons Team
Posts: 423
Joined: 2017-01-14, 02:40
Location: Philippines
Contact:

Re: Epyrus version number handling: Any one have thoughts on it?

Unread post by FranklinDM » 2022-09-29, 07:30

My suggestion is more or less the same as moonbat's. Perhaps it would be best to just use the display version on the about window and other application-specific parts, while for everything else, the Thunderbird-based version will be used (52.6.xxxx). For updates, you'd probably have two version numbers, like so: 2.0.0 and 52.6.2000 if you'd rather not modify and/or make things more complex in the platform. Add-ons would be targeting the analogous Thunderbird-based version instead.

Off-topic:
If it were up to me, I'd prefer a new GUID and change the "base" version entirely, but there's the problem of add-on compatibility, which definitely makes it an unlikely option. :lol:

By the way, once the theme changes are in, we'd be breaking all Thunderbird themes anyway because of the new app menu, especially on Windows, unless we'd have something like Lootyhoof's Theme Compatibility Provider.

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 892
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Epyrus version number handling: Any one have thoughts on it?

Unread post by athenian200 » 2022-09-29, 07:48

Well, I do appreciate the thought, and it has clarified my intentions in my mind. I probably won't go with that suggestion about incrementing the last part of the version number it's exactly what I knew for sure I didn't want to do from the beginning. If I would have been happy with that, I would have done that from the beginning because it was the most obvious and precedented way of going about things.

That is to say, the way I felt about that suggestion helped me figure out that I really am set on moving forward with this solution (or similar) and making it work a little better for me.

Mostly I'm considering extensions rather than themes, because I figure any kind of thing that makes the interface distinctive would break themes. Though honestly I don't care much about stopping users from trying them... not really a fan of the min/max version check that hard blocks install in the first place, at most it should be a warning.
Off-topic:
That said, maybe it's a good thing we're getting all the other improvements in before the big theme change, that way there will be a solid version of Epyrus to work from for anyone who might want to continue the Australis version for the sake of maximum compatibility with old Thunderbird themes. It will be nice to have a usable, mostly stock Thunderbird 52 adapted to UXP available that others can use as a base for their own mail clients without having to undo a lot of custom boilerplate.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 892
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Epyrus version number handling: Any one have thoughts on it?

Unread post by athenian200 » 2022-10-02, 20:30

Well, I've thought more about this... and I'm realizing that I'm really running into all the problems that dual-GUID was intended to solve, I've just been thinking about it backwards.

I've been approaching the problem in my head, as if I were stuck with Thunderbird's old version number and GUID internally so that extensions (and possibly other things I'm not aware of) would work, and just coming up with more elaborate ways to get my version string displayed in all the places that extensions don't care about. That is, I approached this as if I want to lie to users about my application's version number (which would always be the version it forked from internally), and began turning MOZ_APP_VERSION_DISPLAY into a more elaborate way of faking versions in way more places than it was ever intended to be initially. Then somewhere along the line I started thinking about themes and how easily those break compared to extensions, and tried to think of a way to feed my version number to just themes, and before you know it... I saw that it was really going to be another way of doing what dual-GUID already does. The only real advantage of my way is if you needed a way to report two separate version numbers for different purposes while still using the same GUID.

The idea of Epyrus having its own GUID honestly just never (seriously) crossed my mind, because no other UXP-based mail client has done that to my knowledge, so on some level I came to this weird conclusion that if I wanted to avoid doing the 52.6.xxxx thing, I was going to have to create a dual version number hack without using a different GUID somehow. I think the fact that the dual-GUID was labeled as "--enable-phoenix-extensions" misled me into thinking it would only work with Phoenix/Firefox-based applications and couldn't be adapted to a mail client, even though after looking at the code and testing stuff out, there's nothing about it that would make it inherently specific to Phoenix applications.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 33031
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Epyrus version number handling: Any one have thoughts on it?

Unread post by Moonchild » 2022-10-02, 21:15

If it's going to be applied to more than just the browser, I'll be happy to have it renamed to something more generic. calling it "phoenix" is harking back to something that has never even applied to Pale Moon to begin with, anyway. I guess a bit of someone's nostalgia was at the root of that naming.
"The best revenge is to not be like the person who wronged you." -- Marcus Aurelius
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb

Post Reply