Thoughts on the Basilisk Versioning Scheme

[Basilisk-Dev]

What are your thoughts on the Basilisk versioning scheme? Currently it's just the build date. For example Basilisk v2023.10.03 was built on 2023-10-03.

[Moonchild]

I think it's clear and beneficial, but maybe I'm biased.

[athenian200]

I like the way it looks, and I think it makes it very clear when a given version of Basilisk was released. The only potential downside I can think of, is if you needed to release two versions on the same day because there was an issue with a build. There would be no way to tell which build was which...

For instance, let's say I release Epyrus 2.2.0 on the morning of December 25th or something. Then a bug is found immediately, I patch it the same day, and release Epyrus 2.2.1 in the evening on December 25th. There's no problem, it's clear which is the bugfix version and which is the version with the bug.

However, if you release a build of Basilisk on December 25th, then it will be called Basilisk v2023.12.25. Then if there's a problem with that build and you don't want to wait until December 26th to issue a bugfix version, your only choice is to re-issue v2023.12.25, and just tell people the original was recalled and give them a new set of hashes. That is to say, there is no way to distinguish between builds released on the same day. 99% of the time, this doesn't matter... but I could imagine it becoming an issue one day.

There are two basic ways to work around this problem... one is using standard versioning, and the other is simply including the build time as well as the build date. Perhaps something like v2023.12.25T05:00Z for the first build, and v2023.12.25T22:00Z for the second one. Sort of a pseudo-ISO 8601 style.

That's the only reason I think of why you'd want to change it, though.

[ron_1]

I like the way it looks, and I think it makes it very clear when a given version of Basilisk was released. The only potential downside I can think of, is if you needed to release two versions on the same day because there was an issue with a build. There would be no way to tell which build was which...

One could always just add a day to the date (i.e., use tomorrow's date). Probably unlikely that a third release would be needed for the next day. Or maybe use something like v2023.10.03(b) for a quick fix release. But on that note, I do prefer a "normal" version numbering. Then again, I don't use Basilisk.

[RealityRipple]

I get it, but I prefer the Ubuntu method: 2-digit year and month, then optionally any revision numbers. 23.10 is so much less cumbersome than 2023.10.03, and it resolves the two-releases-in-a-day problem by just being 23.12 -> 23.12.1 -> 23.12.2, etc...

[TTraveler]

I get it, but I prefer the Ubuntu method: 2-digit year and month, then optionally any revision numbers. 23.10 is so much less cumbersome than 2023.10.03, and it resolves the two-releases-in-a-day problem by just being 23.12 -> 23.12.1 -> 23.12.2, etc...

I didn't know anything about this method/scheme until now, but after seeing it I very much agree with Ripple, I'd go with that version scheme over the existing...if it has to change at all.

..

[athenian200]

I get it, but I prefer the Ubuntu method: 2-digit year and month, then optionally any revision numbers. 23.10 is so much less cumbersome than 2023.10.03, and it resolves the two-releases-in-a-day problem by just being 23.12 -> 23.12.1 -> 23.12.2, etc...

The only downside is that it introduces a new problem... if Basilisk is still around in 2123, then the versioning number becomes ambiguous. Does 23 refer to 2023, or 2123? Sort of like the Y2K bug, but 100 years later, with 20xx and 21xx instead of 19xx and 20xx.

Still, it does solve the two releases in one day problem, which won't take 100 years to matter.

[TTraveler]

I get it, but I prefer the Ubuntu method: 2-digit year and month, then optionally any revision numbers. 23.10 is so much less cumbersome than 2023.10.03, and it resolves the two-releases-in-a-day problem by just being 23.12 -> 23.12.1 -> 23.12.2, etc...

The only downside is that it introduces a new problem... if Basilisk is still around in 2123, then the versioning number becomes ambiguous. Does 23 refer to 2023, or 2123? Sort of like the Y2K bug, but 100 years later, with 20xx and 21xx instead of 19xx and 20xx.

Still, it does solve the two releases in one day problem, which won't take 100 years to matter.

I would kinda think that nobody here today would care none too much......in 21xx

I sure as spit know I won't be here!!

[RealityRipple]

I get it, but I prefer the Ubuntu method: 2-digit year and month, then optionally any revision numbers. 23.10 is so much less cumbersome than 2023.10.03, and it resolves the two-releases-in-a-day problem by just being 23.12 -> 23.12.1 -> 23.12.2, etc...

The only downside is that it introduces a new problem... if Basilisk is still around in 2123, then the versioning number becomes ambiguous. Does 23 refer to 2023, or 2123? Sort of like the Y2K bug, but 100 years later, with 20xx and 21xx instead of 19xx and 20xx.

Still, it does solve the two releases in one day problem, which won't take 100 years to matter.

If your program lasts another 80 years, then it deserves to have a version number in the 100s. Unlike Chrome.

[Moonchild]

If your program lasts another 80 years, then it deserves to have a version number in the 100s. Unlike Chrome.

^this.

Nobody says you can't have a major version number >= 100

[fatboy]

I like the versioning scheme, it tells you when was the last time it was updated, which I like.
If I have to add a negative, I would say it would be nice to see on which version of Pale Moon it is based? E.g. 2023.10.03 (32.4.1)

[Moonchild]

I would say it would be nice to see on which version of Pale Moon it is based?

Basilisk isn't based on Pale Moon.
They both build on UXP -- they are siblings, in a sense.

[athenian200]

I like the versioning scheme, it tells you when was the last time it was updated, which I like.
If I have to add a negative, I would say it would be nice to see on which version of Pale Moon it is based? E.g. 2023.10.03 (32.4.1)

Off-topic:
Well, if you really want to get into the weeds, then even though technically it's not based on Pale Moon, it is often based on the exact same platform commit (UXP is also sometimes just called "the platform"). These commits are actually labeled in the repo in the following way...

https://repo.palemoon.org/MoonchildProd ... B_20231002

If you look at the tags, you'll see there are a lot of tags with names like RB_<DATE> or RC_<DATE>. I never actually asked MC what RC and RB stand for. I would guess RB is "Release Base" and RC is "Release Candidate," but I could be wrong. So essentially, these tags are the platform commits versions of Pale Moon are built against, and they are helpfully highlighted as good stable release bases for other UXP applications that may want to take advantage of that rather than just taking their chances building against master or finding a good safe commit on their own.

UXP applications share about 90% of their code (though Pale Moon and Basilisk don't include MailNews code, Epyrus doesn't have WebRTC or a way to store bookmarks, something like NetFusion might well have the whole kitchen sink giving you an e-mail client and a browser, etc). Most of the difference between UXP applications is all in their User Interface, branding, and what platform components they choose to compile in or leave out. Basically, if there's a website rendering bug in Pale Moon, it probably affects Basilisk too, because they pretty much share all the code needed to render websites.

It would be safe to say that most of the time, when people speak of a "bug in Pale Moon," they aren't talking about Pale Moon as an application at all. They're talking about platform code Pale Moon incorporates, which is why most website-rendering related bugs you would think of as Pale Moon bugs wind up in the UXP repo, while the only thing you really see in the actual Pale-Moon repo is stuff that affects the UI, application specific scripts that run on top of UXP, or even just changes to preferences or build flags Pale Moon wants to use as default.

I know, I know... that was TL;DR. LOL.

[Basilisk-Dev]

I've ran into the issue with needing to release two builds in a day before. On the 2023.09.12 release I messed up some of the configure options for the Windows builds if I recall correctly. I released a second build called 2023.09.12-r2