-
Notifications
You must be signed in to change notification settings - Fork 289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Branching discussion #1270
Comments
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. |
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 😅 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 😊 |
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 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.
|
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: