Open felixfontein opened 3 years ago
@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 routerosfacts), 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_builtinruntime.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 version
When 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.
community.routeros 0.1.1 has been released.
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 ?
@NikolayDachev which PRs do you mean?
sorry for confusion issues not PRs
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 ;)
I think (if we all agree) next Tuesday is a great date for 1.0.0
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.
1.0.1 with #15 has just been released.
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?
@felixfontein Yes, sounds good ā let's release 1.2.0 šš»
1.2.0 has been released! :tada:
Should we do 1.2.1 after #39 is merge ? Overall is important fix
I think we should, but we should make sure that the fix and changelog fragment are good :)
I've created a stable-1 branch and bumped the main branch to 2.0.0.
Should we create a 2.0.0-a1 prerelease, do some testing without a prerelease, or proceed directly to 2.0.0?
I'm not sure what you mean with "do some testing without a prerelease" ?
About releasing personally I'm more conservative, aka I prefer to no go direct with main release , from other side we should avoid bunch of pre-releases ....
I'm not sure what you mean with "do some testing without a prerelease" ?
You can also test the collection when installing it from git, or when checking it out in a path where ansible-core will find it. I'm doing it for example and am using its main
branch. I don't really use this collection most of the time though, so I'm not actively testing it :) But someone else could test it this way.
About releasing personally I'm more conservative, aka I prefer to no go direct with main release , from other side we should avoid bunch of pre-releases ....
I would also wait a bit more with the final 2.0.0 release. I'm not sure how many people would acually try out a prerelease instead of installing the collection's current main
branch from git...
I would also wait a bit more with the final 2.0.0 release. I'm not sure how many people would acually try out a prerelease instead of installing the collection's current
main
branch from git...
Unfortunately the reality is .. 80% or more of the people always skip reading .. "they pull" after that they open PR's .. :) How we can solve this is a not easy task.
Let's make a prerelease, I don't think we will have a lot, so we can go with the "safe side"
Sounds good. I'll create a pre-release the next days then.
I've just released 2.0.0-a1.
The Bullhorn 32 (https://mailchi.mp/redhat/the-bullhorn-32) has been sent a few days ago, which contains an announcement of 2.0.0-a1 and which asks for feedback. I'd suggest to wait a couple of weeks more, and if nobody reacts until then, make the 2.0.0 release.
Now that we merged some more backwards compatibility breaking changes, how about releasing 2.0.0-a2?
I don't see any reason to not do that so let's go with 2.0.0-a2
I've just released 2.0.0-a2.
Should we plan to release 2.0.0 by the end of this month, if nothing serious shows up until then? We should have 2.0.0 released by November 8th so that it gets included in Ansible 5, but of course we can also release it before that :)
@NikolayDachev @heuels I guess since nobody complained or made another suggestion, it's time for 2.0.0 :) Is it ok for you to release 2.0.0, say, this weekend?
I guess that since nobody replied, it's ok if I do the release today.
2.0.0 has been released! :tada:
2.0.0 has been released! š
Great news ! Congrats all for 2.0.0
Wish you all very merry Christmas and happy new 2022 :)
@NikolayDachev also Merry Christmas a Happy New Year to you, and to everyone else! Enjoy the new year, let's hope it has better surprises than the previous two ones :)
2.1.0 has been released with a ton of new features!
2.2.0 has been released with two new modules and improved licensing marking.
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-collectionsOnce 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!)