community.routeros
community.routeros copied to clipboard
ansible-collections
Release plan
Small collections like this one don't need a complex plan like the one for community.general and community.network. So how about the following?
Release minor and patch releases whenever we want (like after adding new features or fixing bugs). Since this collection is small, there's no need to fix things in advance. Just add features, and after a feature either wait a bit longer for more features/bugs, or make a release.
I suggest releasing form main branch, as described here: https://github.com/ansible/community/wiki/ReleasingCollections#releasing-without-release-branches-for-smaller-collections
Once we release a 2.0.0 (with some breaking change relative to 1.x.y), we can have a stable-1 branch so we can backport bugfixes (or even features) if needed, and release more 1.x.y versions.
(This is essentially what other collections I work on are doing, like community.crypto and community.sops.)
About the next release(s): I would suggest we quickly release a 1.0.0 version, so we can get it included in Ansible 2.10. We should do some testing with the current 0.1.0 release, maybe add bugfixes (or even features), if necessary release a 0.2.0 first, but not wait too long until 1.0.0.
What do you think?
CC @renatoalmeidaoliveira @NikolayDachev @adeptvin1 @heuels
(BTW, I put @heuels and @NikolayDachev as the authors of this collection since they created the plugins and modules in it. I hope that's ok for everyone!)
@felixfontein thank you for doing this.
@heuels and @NikolayDachev please check your emails for an invite to join this repo, and get commit.
Hey,
Thanks !
Will check the release notes (I guess @felixfontein suggestion is ok ) also will try to check / test the repo and api module this days
I have a small collection with different roles which are still in progress (total lack of free time). I switch all roles tasks to use community.routeros.api and they look ok.
just a thought: RouterOS api is new thing however commands and facts probably are already used in lot of users roles. This change to community.routeros.* probably will make some users to be little anoyed about it. For me was easy to do that in a single cmd for all roles/tasks with help of grep,awk and sed etc. but .. My point is, is there any user guidelines for similar changes from the past?
About release plan:
About the next release(s): I would suggest we quickly release a 1.0.0 version
When we can / we should do that (as a date/time frame)?
I have a small collection with different roles which are still in progress (total lack of free time). I switch all roles tasks to use community.routeros.api and they look ok.
:+1:
just a thought: RouterOS api is new thing however commands and facts probably are already used in lot of users roles. This change to community.routeros.* probably will make some users to be little anoyed about it. For me was easy to do that in a single cmd for all roles/tasks with help of grep,awk and sed etc. but .. My point is, is there any user guidelines for similar changes from the past?
There aren't any guidelines yet, since this situation is pretty new :) What's needed to do depends on the version of Ansible that is used.
For Ansible 2.9, which comes with included routeros_* modules (routeros_command and routeros_facts), you have to explicitly use FQCNs to use community.network.routeros_*. These will stop working when users install community.network 2.0.0 (since the modules will have been removed by then), and they manually have to install community.routeros and update their FQCNs (via search+repleace).
For ansible-base 2.10 users which explicitly installed community.network, they either use the old shortname routeros_* or the FQCN community.network.routeros_*. Once they upgrade to community.network 2.0.0, they will get errors if they do not install community.routeros. Once they install community.routeros, thanks to the redirects in community.network their roles and playbooks will just continue to work. If they ever get rid of community.network and just want to use community.routeros though, then they have to update their FQCNs. (Possibilty upgrading to ansible-base 2.11 will solve this, as its ansible_builtin_runtime.yml might get updated once last time, if they are still using the shortname routeros_* from Ansible 2.9 and earlier.)
For Ansible 2.10 users (Ansible 2.10 = ansible-base 2.10 + a set of collections) who upgrade to Ansible 2.11, they have to do nothing. It will just continue to work and use the modules from community.routeros. Ansible 2.11 (ansible-base 2.10 + a set of collections) will include community.network and community.routeros, and thanks to the redirects in community.network both the short names routeros_* and the community.network FQCNs will work. (Ansible 2.12 will probably include ansible-base 2.11, then the shortnames routeros_* will redirect directly to community.routeros.*.)
About release plan:
About the next release(s): I would suggest we quickly release a 1.0.0 versionWhen we can / we should do that (as a date/time frame)?
We can do that today if we want :) I'd suggest to wait a bit, maybe two weeks, just to see if something unexpected shows up.
I'd like to make a 0.1.1 release soon, once ansible-collections/community.network#138 has been merged and 'foreported' to this repo (I hope in the next days). If anyone finds other things to fix/improve, please create PRs :)
Thanks for the info!
We can do that today if we want :) I'd suggest to wait a bit, maybe two weeks, just to see if something unexpected shows up.
I fully agree with that
Since ansible-collections/community.network#138 isn't making any progress, I'll release 0.1.1 now.
What do you think about releasing 1.0.0 of this collection in ~a week? I have two open PRs which should be merged / closed until then.
In case you found anything during testing so far, please report it.
I have a 0 time to check them this days will see if I will be able to find a time ( work,baby and second 4 years old kid .. :) )to help with them .. I think we shuld be ok for 1.0...
I hope to find time to test some more on the weekend, but as of now everything looks OK 🙂
look like the 1st PRs @heuels already work on it .. if need a help to speed up the fix, let me know, the second one look like is going to nowhere so I guess we should be good to go for the next week ?
Haha, ok, that makes a lot more sense :) Yes I agree. Once we released 1.0.0 we can also release 1.0.1 whenever we fixed a bug, there's no need to wait for two months for the next release as in community.network ;)
Next Tuesday is 1.0.0 day then (if nothing comes up over the weekend)! :)
Next Tuesday is 1.0.0 day then (if nothing comes up over the weekend)! :)
Yep Friday is always a bad day for releases or changes ... Monday, I think a majority of the people just not like it for obvious reasons :)
No complaints, and the nightly CI didn't fail, so doing the 1.0.0 relesae now :tada:
1.0.0 has been released: https://galaxy.ansible.com/community/routeros
PR for inclusion in Ansible 2.10: ansible-community/ansible-build-data#35
@felixfontein @NikolayDachev @heuels great work everybody on reaching this major milestone!
@NikolayDachev @heuels If you haven't already, please subscribe to the Ansible Bullhorn email list https://us19.campaign-archive.com/home/?u=56d874e027110e35dea0e03c1&id=d6635f5420 this newsletter contains important information for contributors.
Looks like something went wrong during releasing 1.1.0 (https://dashboard.zuul.ansible.com/t/ansible/stream/b6021035e749489a8e445e1c471986c1?logfile=console.log). I'll ping people on IRC about that...
Ok, it did complete. Just took longer (and had a lot of errors in between - unrelated to us though). The uploaded artefact to galaxy looks good, so it should be fine :)
@heuels I think we should do 1.2.0 soon (as in: end of this week), with #36 and #37. We also have a new feature waiting since end of March (#23)... The next Ansible release will be 4.2.0 beginning of next week, so the new version would get included in there. Does that sound good?
I think we should, but we should make sure that the fix and changelog fragment are good :)