-
Notifications
You must be signed in to change notification settings - Fork 43
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
Query: What version to follow for new collection after rename #226
Comments
@gotmax23 It won't be exact copy as we want to change the documentation where in the word "spectrum virtualize" is used. This would be changed to "storage virtualize" at those places. Please guide as accordingly. |
@gotmax23 I hope I answered your question. Do let me know if any other information is also required. |
Note that you need to declare a redirect in a structured way, so that Ansible would them follow to the new collection automatically. |
Please note that the general process is described in this repo's README: https://github.com/ansible-community/ansible-build-data#renaming-a-collection. Having new modules in the new collection is no problem/plugins, the main thing is that the old modules/plugins are backwards compatible to the ones of the same name in the old collection. |
@felixfontein Thanks for the response. Yes, we had gone through the same link to get hold of renaming requirements. Do you think that this below option would be fine?
|
@Shilpi-J since it's a new collection that's already starting off being stable, I'd go for v1.0.0. |
Thanks @webknjaz
Option 2:
|
@Shilpi-J I'd go for the option 2. Also, you could preserve the original Git history by using the original repo as the base, just pushing it to the new location and adding new commits on top. I'd cut a release right after making the commits that update the metadata (version, name etc.) and the docs + maybe an explanation block at the top of the readme. After this, the new collection would be usable and you could proceed with setting up redirects from the old one.. I'd be eager to hear from @felixfontein, though, since they're more involved with the community than I am. So my concerns may not match the community expectations in full. |
@Shilpi-J I think both is fine. For 1) I would include the docs changes already in 0.1.0 though. But from the community point of view it doesn't really matter, as long as you guarantee that the final release (1.0.0) is backwards compatible for things that worked with the old collection. |
Thanks @felixfontein @webknjaz We will proceed with option 2) mentioned above and will have v1.0.0 as first release. |
@felixfontein We got one request/question internally to have this new collection storage virtualize version as 2.0.1 as the deprecated spectrum virtualize version would be 2.0.0. We want to have new collection release version as 2.0.1 to avoid any confusion with the users. |
@Shilpi-J you can also do a 2.0.1 bugfix release with no changes, but you cannot use 2.0.1 as an initial release. Use 2.0.0 for that if you prefer 2.x.y. |
Thanks @felixfontein for the response.Let me get back to my team and share the inputs, will confirm you which version we are going ahead. |
Hi Team,
We plan to rename the existing IBM Spectrum Virtualize Ansible collection to IBM Storage Virtualize ansible collection
Thanks
The text was updated successfully, but these errors were encountered: