Closed BGmot closed 3 weeks ago
ya, I wish I had branched a 3.0 release instead of putting all of my changes into main. I'm not smart enough to undo those. Any of you?
I keep updating all the modules to be compatible with Zabbix 7.0 in my own fork and only when I happy with all the test I'll submit a PR.
We can easily move your 3.0 related commits to different branch and roll them back in main leaving only bug fixes in main. I am just debating (with all of you and with myself) whether it is worth doing that). The problem is a switch to Zabbix 7.0 (I personally would wait at least until 7.0.3) will be not immediate and majority of users will be still using this collection for 6.0 and 6.4.
Ya I don't know. I'm ready to get this stupid release out. They tool a lot longer to get 7.0 released then I expected lol. I could honestly go either way.
I don't see any reason why support for Zabbix versions should be tied into major version releases of this collection :) I think you guys should proceed with 3.0 if you feel like it and add Zabbix 7.0 later down the road as minor release as adding new version shouldn't be backwards incompatible, whereas dropping supported version should.
Btw, waiting for 7.0.X is a good idea, because I encountered situations in the past where I did some workaround due to a "new and undocumented" way we were supposed to use the API, only for them to revert it back instead of documenting it :sweat_smile: Zabbix have had terrible release notes in the past when it comes to the API.
And as always, thank you for all the quality for you guys are doing :blush:
We want to go with 3.0 because we do have some breaking changes. 7.0 is released today. I think this discussion can be closed, no need to fork new branch, let's just release 3.0. Let's proceed discussion in https://github.com/ansible-collections/community.zabbix/issues/1242 Thanks @D3DeFi for your thoughts as usual!
I would go for - before merging the first PR that does something with Zabbix 7.0 - making a release. Then merge the PR and work on other 'stuff' that you want to, either releated to Zabbix 7.0 or not.
People should be aware that when they make use of the main
version that this is the latest and greatest. If you use this in any way professionally, then you should already have pinned it to a version as this is basically 'common sense in it'.
When it includes breaking changes, as it is Zabbix 7.0 related, then it should be obviously mentioned in some documentation and I believe in the versioning as well. So a 2.x is < Zabbix 7.0, and 3.0 would be >= Zabbix 7.0 showing any use that it includes breaking changes.
My 2 cents.
On modules level I managed to update all the modules that failed with Zabbix 7.0 to support both < 7.0 and 7.0 so no breaking changes here. @pyrodie18 how are you doing on roles side? So far I see these breaking changes:
Have not touched 7.0 yet. Was trying to get the breaking changes in there first.
I think the last real breaking change I have left to do is remove support for 6.2 and 6.4 within the roles which shouldn't take but a few minutes.
Don't remove 6.4 for now please it is widely in use. We need to release new version that fully supports 6.0, 6.4 and 7.0.
So we we want to update what we're supporting in the documentation? https://github.com/ansible-collections/community.zabbix?tab=readme-ov-file#supported-zabbix-versions
So we we want to update what we're supporting in the documentation? https://github.com/ansible-collections/community.zabbix?tab=readme-ov-file#supported-zabbix-versions
I think it is up-to-date - we support what Zabbix fully supports.
I think it is up-to-date - we support what Zabbix fully supports.
OK, just looked and didn't realize they hadn't retired 6.4
I see bug fixes keep coming. Should we release the last 2.5.x right before we release 3.0.0? If yes how should we branch our work for 3.0 (Zabbix 7.0)? @pyrodie18 @D3DeFi @dj-wasabi I'd love to hear your opinion. And anybody else sure please feel free to chime in.