search

ansible-community / ansible-build-data

Holds generated but persistent results from building the ansible community package
https://ansible.readthedocs.io/projects/ansible-build-data/
GNU General Public License v3.0
120 stars 43 forks source link

Query: What version to follow for new collection after rename #226

Open Shilpi-J opened 1 year ago

Shilpi-J commented 1 year ago

Hi Team, We plan to rename the existing IBM Spectrum Virtualize Ansible collection to IBM Storage Virtualize ansible collection

Thanks

gotmax23 commented 1 year ago

What is the current FQCN [^1] and what will be the new one? Will the contents be exactly the same?

[^1]: Fully Qualified Collection Name (i.e. NAMESPACE.NAME)

Shilpi-J commented 1 year ago

@gotmax23 The old collection name is ibm.spectrum_virtualize (https://github.com/ansible-collections/ibm.spectrum_virtualize) The new collection name is ibm.storage_virtualize (https://github.com/ansible-collections/ibm.storage_virtualize)

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. Also, we plan to release some new additional modules and features in the new collection.

Please guide as accordingly.

Shilpi-J commented 1 year ago

@gotmax23 I hope I answered your question. Do let me know if any other information is also required.

webknjaz commented 1 year ago

where in we are required to mention the redirects to the new collection.

Note that you need to declare a redirect in a structured way, so that Ansible would them follow to the new collection automatically.

felixfontein commented 1 year ago

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.

Shilpi-J commented 1 year ago

@felixfontein Thanks for the response. Yes, we had gone through the same link to get hold of renaming requirements. But since the documentation of all the modules will get changed due to change in name of brand altogether (spectrum being replaced with storage), thats why I asked this question .. what version should we give? Although, the functionality remains same in both the collections.

Do you think that this below option would be fine?

webknjaz commented 1 year ago

@Shilpi-J since it's a new collection that's already starting off being stable, I'd go for v1.0.0.

Shilpi-J commented 1 year ago

Thanks @webknjaz Do you think that below option can also be used? Option 1:

Option 2:

webknjaz commented 1 year ago

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

felixfontein commented 1 year ago

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

Shilpi-J commented 1 year ago

Thanks @felixfontein @webknjaz We will proceed with option 2) mentioned above and will have v1.0.0 as first release.

Shilpi-J commented 1 year ago

@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. I hope that should also be fine. Thanks

felixfontein commented 1 year ago

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

Shilpi-J commented 1 year ago

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.