[Infractem]

What are the risks of updating from to the latest version of amx? Are there chances that some old plugins and modules not working at all?

[fysiks]

AMX Mod X 1.8.2 is the latest stable release of AMX Mod X. If you update to a beta version like 1.8.3-dev, you take the risk of something not working (this is why it's called a beta). Since the beta version of any software is changing often, it's hard to know if the one version that you got has any significant bugs. Having said that, many people have switched to 1.8.3-dev without serious side effects. The only way to tell it so try it out. I'd recommend backing up your whole AMX Mod X installation before upgrading though.

[DeNeDe]

Yeah, 1.8.3 works fine..just with some minor changes and problems.

[klippy]

Originally Posted by DeNeDe Yeah, 1.8.3 works fine..just with some minor changes and problems.

Then report those 'problems' and help people fix it.

[meTaLiCroSS]

Bad thing of 1.8.3 is they upgraded and updated a LOT of things and they keep doing it. so there's no top limit for it, it has been on beta since.. years

[Arkshine]

@meTaLiCroSS, there are few reasons for this. Like there are a lot of things to fix/improve in AMXX, there are not many people willing to help (reporting, testing, creating PR, etc.) and I suck to manage projects. There are things it can't be helped but there are definitively room for improvements. Anyway, we need a release this year and a better communication on what's happening. I guess what we should do first is to make a changelog of what we did since 1.8.2 to get an overview of the whole thing, making a checklist of what we really need for the next version (as few as possible), making some announcement about it, then later putting the dev in frozen state and involving more people to test. Ideally releasing something as soon as possible and switching to a rolling release cycle like SourceMod.

[addons_zz]

> I guess what we should do first is to make a changelog of what we did since 1.8.2 to get an overview of the whole thing

I would advise to not create change logs only near the release. For each update which produces a change from the user point of view, add it to a change log progressively kept up to date. On this case the change log can be too extent, then split it into two parts, one detailed and one overall.

Letting to do a full file near the release is over killing and over boring, I think, splitting the boringness across across the project development is much better. But may others like to do everything on the end, but it could significantly reduces the accuracy/quantity of the information, as what was done could be mostly long forgot.

For anyone not familiar with change logs, do not put on change log things like I renamed variables, we changed the code style to Allman, and etc, but things like, we fixed crashes, double performance, added the new setting X, changed the menu Y color to Z.

[JusTGo]

Originally Posted by Arkshine @meTaLiCroSS, there are few reasons for this. Like there are a lot of things to fix/improve in AMXX, there are not many people willing to help (reporting, testing, creating PR, etc.) and I suck to manage projects. There are things it can't be helped but there are definitively room for improvements. Anyway, we need a release this year and a better communication on what's happening. I guess what we should do first is to make a changelog of what we did since 1.8.2 to get an overview of the whole thing, making a checklist of what we really need for the next version (as few as possible), making some announcement about it, then later putting the dev in frozen state and involving more people to test. Ideally releasing something as soon as possible and switching to a rolling release cycle like SourceMod.

https://forums.alliedmods.net/showthread.php?t=275819

ShowMenu and VGUIMenu are bugged in amxx1.8.3 in 1.8.2 they work fine.

[fysiks]

Originally Posted by addons_zz > I guess what we should do first is to make a changelog of what we did since 1.8.2 to get an overview of the whole thing I would advise to not create change logs only near the release. For each update which produces a change from the user point of view, add it to a change log progressively kept up to date. On this case the change log can be too extent, then split it into two parts, one detailed and one overall. Letting to do a full file near the release is over killing and over boring, I think, splitting the boringness across across the project development is much better. But may others like to do everything on the end, but it could significantly reduces the accuracy/quantity of the information, as what was done could be mostly long forgot. For anyone not familiar with change logs, do not put on change log things like I renamed variables, we changed the code style to Allman, and etc, but things like, we fixed crashes, double performance, added the new setting X, changed the menu Y color to Z.

The problem with generating the changelog "on the fly" is that you would still need to go back and verify every entry because not all commits are guaranteed to be kept. So, it's probably best to generate a changelog based on the commit log (when the code is frozen as 'feature complete') so that you can more easily detect when a commit/feature was reversed.

[addons_zz]

> because not all commits are guaranteed to be kept

The change log is not based per commit, I mean for each commit there is a change log entry. But new things like features added can be reversed, however while reversing, it also applies to update the change log removing the entry, if it was added for this release, or adding a new entry, if we are removing something from published release.


Update:

Seems also fine also just to review the commit history to write a change log. Then just do what you prefer most, to do everything at once, or to split it over time.