Update Rock-on Readme to highlight process for changing existing Rock-ons

[Hooverdan96]

@FroggyFlox - I think it would be a good idea to add your findings to the contribution section of the Rock-on readme with respect to making changes to existing Rock-ons.
Maybe something to the effect that if the underlying docker image is changed (due to deprecation or moving from unofficial to official image, etc.) the process has to be to create a new Rock-on and, if applicable, deprecate the old one. I assume, if a specific version (like we have discussed during the postgresql Rock-on) is locked in via the version tag, it would also be recommended to create a new Rock-on rather than updating an existing one (though, if it ever happens that the version tag is surfaced in the installation UI, this would likely not be an issue anymore).
On the flip side, other changes to Rock-ons (like description/info updates, as well as add/subtract variables/switches) can be done directly on the existing Rock-on and only represent a version change.

Or should the recommendation always be to create a new one/deprecate the old one?
Just adding @phillxnet for his 2 cents as well.

[FroggyFlox]

Hi @Hooverdan96 ,

That is a very good idea, and one that will help everybody.

I agree with your suggestion:

• create a new rock-on if no rock-on already exists for the project of interest
• create a new rock-on if a rock-on already exists for this project but the proposed rock-on will use a different image. In this case, it is advised to deprecate the old one
• do not create a new rock-on but update the current one if changes do not involve the use of a different image

You could place this in the "How do I create my own app" section, or maybe in its own separate section... I'm undecided:
https://github.com/rockstor/rockon-registry#how-can-i-add-my-own-app

We should also include this information in our documentation (http://rockstor.com/docs/contribute_rockons.html) once we have the content decided.

Thanks a lot for sharing this idea, that's definitely information we should have. Once we have all of that set, we could also think of linking to these resources (readme and rockstor documentation) while creating proper "contributing guidelines (as per Github's feature).

[Hooverdan96]

May be a small section before the "One Time Setup" right after the "How can I add my own app". The title could be something like:
"What Do I have to consider before adding or updating a Rock-on?" And then list the best practices above like you have done in other areas.