Author Topic: Possible new version scheme  (Read 5709 times)

0 Members and 1 Guest are viewing this topic.

Offline m!m

  • 211
Possible new version scheme
I want to propose changing the version number scheme FSO uses to something that uses the year of release instead of an arbitrary version number. I proposed this on discord already and received some positive answers there so I wanted to open the discussion to the entire community.

The primary reason for this proposal is to improve the current versioning scheme where a new major version bump (e.g. 3.7 to 3.8) happens more or less arbitrarily. In this new versioning scheme the major version (the first number of the version) would be the year of release. At the moment that would be 18 instead of 2018 to keep the version short. At the start of the year the minor version (the second number in the version) would be reset to 0 and incremented before each release. For example, all builds before the next release would be 18.0.xx and the next final release would be 18.1 and if there is another one this year it would be 18.2.

Nightly builds would use the "patch" part for their date version which would look like this: 18.0.20180526. Since a final release increases the minor version part, nightly builds from before that will continue to be considered "less" than the final release which should ensure that any version checks (e.g. by Knossos) still work correctly.

Please let me know what you think about this change. If there are no serious issues it could be implemented before the next final release or that release could be the last to use the "old" versioning scheme.

 

Offline Novachen

  • 29
  • The one and only capella supernova
    • Twitter
Re: Possible new version scheme
Well from my point of view.

Maybe some of you know it, that i developed a complete own branch of the source code (which was incompatible to FSO) from 2006 until 2017 and that was used primariliry for the console ports of FS2. I actually always used the year as the first number of the builds.

So i am still familiar with it. Even i made the version even shorter, because the last build i developed was simply called 2017-44... the 44th build of the year 2017.

Quote
18.0.20180526
Why not 2018.05.26?

Well, maybe i still do not have a clue about it... but what make a release to a final release anyway? If i look back to 3.8.0... it is nearly useless to me since the time the unicode features were introduced.
In the same way, you can declare one of the nightlies to a final release on a monthly basis...
« Last Edit: May 26, 2018, 01:50:43 pm by Novachen »
Female FreeSpace 2 pilot since 1999.
Former Global moderator in the German FreeSpace Galaxy Forum.
Developer of NTP - A Multi-Language Translation Library Interface, which allows to play FreeSpace in YOUR Language.

Is one of my releases broken or not working? Please send a PM here, on Discord at @novachen or on Twitter @NovachenFS2, a public tweet or write a reply in my own release threads here on HLP, because these are the only threads i am still participating in.

 

Offline Spoon

  • 212
  • ヾ(´︶`♡)ノ
Re: Possible new version scheme
Why not 2018.05.26?
Agreed.
20180526 is hard to read at a glance.
Urutorahappī!!

[02:42] <@Axem> spoon somethings wrong
[02:42] <@Axem> critically wrong
[02:42] <@Axem> im happy with these missions now
[02:44] <@Axem> well
[02:44] <@Axem> with 2 of them

 

Offline m!m

  • 211
Re: Possible new version scheme
That version is not intended to be seen by users. "2018.05.26" would break a lot of things since a comparison with "2018.1.0" (a final release that happens later that year) appears to be less recent than the old nightly build. The "20180526" is already in use for nightly builds and is working very well so far so there is no reason to change that particular aspect.

 

Offline Spoon

  • 212
  • ヾ(´︶`♡)ノ
Re: Possible new version scheme
That version is not intended to be seen by users. "2018.05.26" would break a lot of things since a comparison with "2018.1.0" (a final release that happens later that year) appears to be less recent than the old nightly build. The "20180526" is already in use for nightly builds and is working very well so far so there is no reason to change that particular aspect.
"Working very well" Nah, its unreadable at glance and bad.
"No reason to change" Oh okay then, if its coder law to make things user unfriendly for no apparant reason, who am I to question it.

Define who you see as 'users'. If I'm not one of them, then who is?
Urutorahappī!!

[02:42] <@Axem> spoon somethings wrong
[02:42] <@Axem> critically wrong
[02:42] <@Axem> im happy with these missions now
[02:44] <@Axem> well
[02:44] <@Axem> with 2 of them

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: Possible new version scheme
We have to have a way to differentiate nightly and stable builds. If we say that "2018.1" or "18.1" is the first stable build released in a year, that's clear and readable; it also lets us define rules by which versions can be compared easily. 18.1.0 is always going to be "lesser" than, say, 18.1.20180526, while 18.0.20180101 is always going to be "lesser" than 18.1.0. By making the build date the entirety of the version number, we lose the easy difference between stable and nightlies.

So, Spoon, what is more important? Figuring out the difference between nightlies and stable, or figuring out which specific nightly you're using? Personally, I think that differentiating between nightlies or stable builds at a glance is more important than identifying specific nightlies at a glance; Any versioning scheme that we adopt has to serve both needs. Which need takes priority is up for debate, but both needs must be served, and I think that m!m's proposal is perfectly workable in this regard.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Spoon

  • 212
  • ヾ(´︶`♡)ノ
Re: Possible new version scheme
From my personal experience and usage, its absolutely more important to figure out the difference between specific nightlies. Why? Because whenever I run into a bug, its always me who has to search through a gazillion different nightly builds to figure out the exact one where something went bad. I know this never factors into any coder decisions, because the burden of figuring out at what point the bug occures is always shifted to the one reporting it.
The so called stable builds are basically never actually useful to me. Therefore I don't really care what kind of name or number you give them. Selfish? Maybe. Can you answer my question earlier? If I'm not a user, then what am I? I'm one of the people who is constantly dealing with nightlies and the like. The players are just going to get whatever is the latest offical build. As long as the name is clear enough to them, does it matter? I bet they won't lose any sleep over it. Or an hour of going through nightlies.
Urutorahappī!!

[02:42] <@Axem> spoon somethings wrong
[02:42] <@Axem> critically wrong
[02:42] <@Axem> im happy with these missions now
[02:44] <@Axem> well
[02:44] <@Axem> with 2 of them

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: Possible new version scheme
You have good points, but those points lead me to ask whether or not we actually need to have "stable" builds at all anymore. If we have no need to differentiate between two kinds of builds, then your proposal would be the most intuitive way to go.

Now that we have Knossos, we have a way to deliver up-to-date builds to players without those players having to navigate forum threads, so the main reason to have stable builds as a defined entry point for new players has basically fallen away.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 
Re: Possible new version scheme
As someone who had to perform binary searches over years of nightlies to track down a specific one where something started going wrong I'm with Spoon on this one.

If there's a problem differentiating nightlies and stable builds you can simply add a lowercase n before a nightly.

So a stable release this year would be 18.1 while a nightly would be n_18.05.26._18.1. n for nightly, then date for readability, then major version(so you can tell at a glance whether a specific nightly is before or after a "stable" release. An additional benefit is that builds would automatically be sorted by date in alphabetic order and nightlies would be 'seperate' from the stable releases in your folder.
Or change that 'n' to 'dev' to even further clarify what these builds are. Just put the date right after and make it easy to parse at a glance.

I don't think doing away with stable builds completely is all that great either. Knossos can keep you on a stable build and only update when a new one comes out, sure, but they're good milestones when trying to track down an issue and not everyone uses Knossos. It's technically still in beta too which might make new players go the more "traditional" route in which case stable milestone builds provide a good starting point.


Mod devs(and testers) are the ones going through nightlies the most and the naming scheme should probably be tailored for them rather than your average Knossos using player.
« Last Edit: May 26, 2018, 04:18:22 pm by FrikgFeek »
[19:31] <MatthTheGeek> you all high up on your mointain looking down at everyone who doesn't beam everything on insane blindfolded

 

Offline m!m

  • 211
Re: Possible new version scheme
The versions should be compatible with the semver style to make parsing the version numbers easier for Knossos and other launchers. "n_18.05.26._18.1" is hard to parse especially if it's a versioning format which is specifically built for FSO.

If final releases are not going to be done anymore then we could switch to a monthly "stable" build which would have more build options (e.g. SSE2 and AVX). It could also be marked as "stable" in Knossos so that people would receive updates rarely instead of every day when a new nightly build has been compiled.

In that case, 18.5.26 would make sense again since there would be no release builds which would screw up the version comparison.

 

Offline jr2

  • The Mail Man
  • 212
  • It's prounounced jayartoo 0x6A7232
    • Steam
Re: Possible new version scheme
How are new players going to be able to tell that the newer versions are newer than the current 3.8.0?  If you had a blind choice between 3.8.0 and 18.1 yeah you'd probably choose 18.1 but it would be confusing.  Maybe just the date on the executable + a debug prefix if debug, with the version number kept internal?  I dunno.  I'm also tired which means I'm probably not parsing this entirely logically.  As long as the "normal" users aren't left scratching their heads, everyone else can probably figure it out (but it would be nice if it worked for everybody seamlessly without too much effort).

 

Offline m!m

  • 211
Re: Possible new version scheme
Well, I would assume that people would just pick the build which is linked in the forum post. Then again, people do show up with ancient builds like 3.6.9 some times so that system isn't entirely fool-proof either.

Ideally, the build downloading would be handled by Knossos for most users and only advanced users would download their builds manually.

 

Offline jr2

  • The Mail Man
  • 212
  • It's prounounced jayartoo 0x6A7232
    • Steam
Re: Possible new version scheme
Well, I would assume that people would just pick the build which is linked in the forum post. Then again, people do show up with ancient builds like 3.6.9 some times so that system isn't entirely fool-proof either.

Ideally, the build downloading would be handled by Knossos for most users and only advanced users would download their builds manually.

Most likely because they get FSO from a 3rd party mod site, or maybe part of a TC download that included an old engine.  Knossos can help alleviate that if we can spread that around as the best distribution method for all FS2 engine mods & TCs.   You'll still get the odd person popping in with 3.6.9 or whatever build came with The Babylon Project torrent or whatever, as well as people that had it, forgot about it, and finally pulled it out of the archives from their old HDD or paperweight computer.

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Possible new version scheme
There's a middle ground between 2018.05.26 and 18.0.20180526; it could be something like 18.0.1-2018-05-26.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline ngld

  • Administrator
  • 29
  • Knossos dev
Re: Possible new version scheme
Another option would be something like 2018.05.26-1+stable.  The -1 suffix is used to differentiate between multiple builds done on the same day, the + suffix is ignored by Knossos for version comparisons but can be used to mark stable or nightly builds for humans.

 

Offline Spoon

  • 212
  • ヾ(´︶`♡)ノ
Re: Possible new version scheme
You have good points, but those points lead me to ask whether or not we actually need to have "stable" builds at all anymore. If we have no need to differentiate between two kinds of builds, then your proposal would be the most intuitive way to go.

Now that we have Knossos, we have a way to deliver up-to-date builds to players without those players having to navigate forum threads, so the main reason to have stable builds as a defined entry point for new players has basically fallen away.
I spend some time mulling over this, I think you brought up a interesting point. But my mulling didn't really produce any new amazing insights or anything. So I'm just going to take the easy way out and agreed with Frikg.
Urutorahappī!!

[02:42] <@Axem> spoon somethings wrong
[02:42] <@Axem> critically wrong
[02:42] <@Axem> im happy with these missions now
[02:44] <@Axem> well
[02:44] <@Axem> with 2 of them

  

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
Re: Possible new version scheme
Another option would be something like 2018.05.26-1+stable.  The -1 suffix is used to differentiate between multiple builds done on the same day, the + suffix is ignored by Knossos for version comparisons but can be used to mark stable or nightly builds for humans.

I'd suggest doing it the other way round. Stable builds just get a date, nightly builds get a label in the file name.
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 

Offline chief1983

  • Still lacks a custom title
  • Moderator
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Re: Possible new version scheme
Do stable builds need a full date?  Many projects are just using year/month these days, such as 1803 (see the latest Win10 release) or 18.04 (see the latest stable Ubuntu release).  Unless we plan to have a release process that can flag and release stable builds more than once a month that might be excess noise, when simply trying to refer to a specific stable build.  Internally the version could be expanded out more if it helps with our own systems but the user of a stable build probably doesn't need to know too many numbers when differentiating.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline m!m

  • 211
Re: Possible new version scheme
The internal version needs the full date to make sure that nightly and release builds can be sorted correctly but I see no reason to add the full date to the release post.

 

Offline DahBlount

  • Moderator
  • 29
  • Alpine ☆ Cancer Tribulation
    • Minecraft
    • Skype
    • Steam
Re: Possible new version scheme
Alright folks, here's the scoop:
Proposed new versioning scheme will use the year of release as the major version and the minor version will be updated on a 4 month development cycle. As with the current scheme, minor numbers will be even for stable and odd for unstable.

The 4 month development cycle will involve a concurrent RC phase during the last 2 weeks, where people should prioritize bugs, particularly older bugs as we have a fair amount of technical debt between github, coverity, and mantis.

Additionally, if we can't get the monthly newsletters up and running again soon, I would like to propose a monthly "What's new with the codebase" forum post as a way of informing users on what actually got added or fixed.
« Last Edit: December 21, 2018, 12:43:44 pm by DahBlount »
<Axem> yet still more insightful than #hard-light

<Axem> jad2.23 will just be cat videos

<DahBlount> So
<DahBlount> JAD2.2 is like that
<Axem> maybe
<Axem> it can be whatever you like!
<DahBlount> A Chocolate Sundae?
<Axem> sure

My models: GTF Gilgamesh - GTD Nuadha [Redesigning] - Ningirama [WIP] - GTG Zephyrus