Release plan - Githubissues

felixfontein commented 4 years ago

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 commented 2 years ago

2.2.1 has been released with some bugfixes for the new modules.

felixfontein commented 2 years ago

2.3.0 has been released with some bugfixes and new features.

NikolayDachev commented 2 years ago

@felixfontein Thank you !!!

bigdestroyer commented 2 years ago

Curious, can one run with one play the playbook to multiple devices at once? I would like to make an inventory file with all the mikrotik devices inside and run the playbook against it. Would help for bulk provisioning/applying changes. Looking at the examples it seems you can only do 1 router per play before having to change the playbook.

felixfontein commented 2 years ago

@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 commented 2 years ago

2.3.1 has been released with improved documentation.