The answer is: when contributors help us close issues marked for 1.4 milestone.
1.4 is the release version of 1.3First you'll have to get 1.3 out before even thinking about releasing 1.4
Are they going the same stupid versioning route as phone makers where they randomly decide to skip increments? Same shit goes for Microsoft with Windows too1.4 is the release version of 1.3
Why should 1.3 release be called 1.3 at this point when it's been so long in development? When people say 1.3 nowadays you have absolutely no fucking clue which point in the development cycle they compiled 1.3 at, you have no idea what's been fixed or implemented. At least making it 1.4 as release, when people say 1.4 you know they'll mean the release version instead of the development version.Are they going the same stupid versioning route as phone makers where they randomly decide to skip increments? Same shit goes for Microsoft with Windows too
Are they going the same stupid versioning route as phone makers where they randomly decide to skip increments? Same shit goes for Microsoft with Windows too
I dont like that versioning convention to be honest, but i get your point.We call the next tagged release TFS 1.4, not 1.3. Making version (1.2, 1.4, 1.6) officially tagged releases, and odd versions (1.3, 1.5, 1.7) development versions.
That way, when people say "I use TFS 1.3" then we know they refer to this development phase (which could mean they have a compiled server anywhere between 2016 - 2020). When they say "TFS 1.4" we know they refer to the official release (or based). When they say "TFS 1.5" we know they refer to the next dev phase. etc
Tagging the next version TFS 1.3 would be a major headache since there has been so much implemented since 2016, and we have no idea at what point in the dev cycle they refer to, or if they refer to the official release.
I hope our TFS version logic is not something people consider as "stupid", to me it makes sense and add more clarity at least.
Show your better versioning convention that you actually like. I want to see itI dont like that versioning convention to be honest, but i get your point.
I didn't say i had one better for this purpose and how things has been done till now, i said i dont like it.Show your better versioning convention that you actually like. I want to see it
I didn't say i had one better for this purpose and how things has been done till now, i said i dont like it.
If all the versioning were done better since 1.X started, the minors version could only be used for real stable versions (1.2, 1.4) and you could use the patch number when adding important and relevant stuff (development versions)
That way we would probably be now releasing 1.2.0, but had 1.1.1, 1.1.2, 1.1.3.. .whatever.
I know this requires working with more iterations in the codebase and someone deciding when to cut and create new patch version. But i really think would be better.
Here are my thoughts, keeping in mind that I'm too stupid to comprehend smart C++ stuff, and I havent played cip tibia in 10 years. (thus unable to properly contribute to behavior testing).Ok so let's break it down:
- creatures stacking - ready, needs testing only
- monsters pathing/isSightClear - WIP, but solution was found and it moves forward fast now
- scheduler timers - what's going on there? I have no idea what they talk about. How far is it from being finished? Explain it to me like I'm 5
I talked with Nekiro on discord, he proposed Xiaolin Wu algorithm (and confirmed that it gives desired results after some adjustments), but the code itself has to be adapted to TFS. I agree on his solution if it helps. I will be looking into that algorithm tomorrow.monsters pathing/isSightClear - Need testing, the devs seem to be in algorithm deadlock and doesn't quite seem agree on provided solution
Show your better versioning convention that you actually like. I want to see it
Good read.
here