Release plan

[felixfontein]

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!)

[gundalow]

@felixfontein thank you for doing this.

@heuels and @NikolayDachev please check your emails for an invite to join this repo, and get commit.

[NikolayDachev]

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

[NikolayDachev]

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?

[NikolayDachev]

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)?

[felixfontein]

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?

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 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 :)

[NikolayDachev]

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

[felixfontein]

Since ansible-collections/community.network#138 isn't making any progress, I'll release 0.1.1 now.

[felixfontein]

community.routeros 0.1.1 has been released.

[felixfontein]

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.

[NikolayDachev]

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...

[heuels]

I hope to find time to test some more on the weekend, but as of now everything looks OK 🙂

[NikolayDachev]

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 ?

[felixfontein]

@NikolayDachev which PRs do you mean?

[NikolayDachev]

sorry for confusion issues not PRs

[felixfontein]

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 ;)

[NikolayDachev]

I think (if we all agree) next Tuesday is a great date for 1.0.0

[felixfontein]

Next Tuesday is 1.0.0 day then (if nothing comes up over the weekend)! :)

[NikolayDachev]

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 :)

[felixfontein]

No complaints, and the nightly CI didn't fail, so doing the 1.0.0 relesae now 🎉

[felixfontein]

1.0.0 has been released: https://galaxy.ansible.com/community/routeros

[felixfontein]

PR for inclusion in Ansible 2.10: ansible-community/ansible-build-data#35

[gundalow]

@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.

[felixfontein]

1.0.1 with #15 has just been released.

[felixfontein]

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...

[felixfontein]

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 :)

[felixfontein]

@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?

[heuels]

@felixfontein Yes, sounds good — let's release 1.2.0 👍🏻

[felixfontein]

1.2.0 has been released! 🎉

[felixfontein]

@bigdestroyer please do not post questions in issues that are used for something completely different. I've locked this issue so this won't happen again.

To answer your question (please create a new issue if you want to discuss this in more detail): of course you can do that. The examples mainly try to show how something works in a simple case, so they stick to a simple(r) operation for one router. But you can easily run them against multiple routers, switches, or other MikroTik devices at the same time.

[felixfontein]

2.3.1 has been released with improved documentation.

[felixfontein]

2.4.0 is out with quite a few improvements for the API modules.

[felixfontein]

2.5.0 is out with new features and a bugfix for the API modules.

[NikolayDachev]

@felixfontein Thank you !!!

[felixfontein]

@NikolayDachev thanks! @therfert also deserves a lot of credit for quite a few of the new feature/bugfix PRs!

[felixfontein]

2.6.0 has been released with new features and bugfixes.

[felixfontein]

1.2.1 and 2.7.0 are out. I noticed that we backported some bugfixes to the stable-1 branch some longer time ago, but never released them; 1.2.1 contains them. 2.7.0 has a fix and new features for the new api modules.

[NikolayDachev]

Thank you !

[felixfontein]

2.8.0 is out with new features and bugfixes! Thanks to everyone who contributed!

[felixfontein]

2.8.1 is out with a bugfix.

[felixfontein]

2.8.2 is out with another bugfix.

[felixfontein]

2.8.3 has been released with updated documentation that now uses semantic markup.

[felixfontein]

2.9.0 has been released with support for new API paths and fixed support for existing paths.

[felixfontein]

2.10.0 is out with a bunch of new features w.r.t. API paths!

[felixfontein]

2.11.0 has been released with new features and bugfixes.

[felixfontein]

2.12.0 has been released with new features and bugfixes.

[felixfontein]

If anyone still uses the 1.x.y versions, please take a look at #252. I'm proposing to declare the stable-1 branch as End Of Life.

[felixfontein]

2.13.0 has been released with new features and bugfixes.

[felixfontein]

1.2.2 has been released, making the stable-1 branch effectively End of Life. There will be no further 1.x.y release. (Ref: #252)

[felixfontein]

2.14.0 is out with new features.

[felixfontein]

2.15.0 is out with more new features!

[felixfontein]

2.16.0 is out with more new features!

[felixfontein]

2.17.0 is out with new features!

[felixfontein]

I'm planning to create a new major version in end of October / beginning of November (for Ansible 11's feature freeze). Ref: #308.

[felixfontein]

2.18.0 is out with a bugfix, several new features (including a restrict feature for api_info and api_modify), and a deprecation of support for ansible-core < 2.15 for the next major release.

[felixfontein]

2.19.0 is out with some more API module related improvements.

[felixfontein]

2.20.0 is out. Tomorrow I'll merge the 3.0.0 PR (#318) and then someone next week there'll be 3.0.0 with some breaking changes.

[felixfontein]

3.0.0 is out, which removes support of EOL Ansible/ansible-base/ansible-core versions and fixes check mode of the community.routeros.command module. The 2.x.y release stream will only receive bugfix releases (2.20.x) from now on.

[felixfontein]

3.1.0 is out with bugfixes and features.