I have written earlier about a new concept for chemmacros and about the current development of chemmacros. I really want to go along with e idea of modularity. In fact so much that I already have a draft completed (without manual and probably a number of bugs but still…). The big question is, though: How do I procede without annoying all the users of chemmacros? If I am consequent with the modularity then there need to be breaking changes.
Currently I see three options of how to procede:
- Make the changes, publish the new chemmacros and live with the fact that users will be annoyed.
- Publish the new version as new package (name?) and deprecate chemmacros. This would mean people would eventually need to change packages if they want new features and bug fixes. chemmacros could issue a warning when loaded that it is deprecated and that there is a successor. Similar changes are not unprecedented: think of glossary and glossaries, or the various unit packages and siunitx.
- Add loads and loads of compatibility code which gently directs users towards the new syntax/option names/… – this is the version I favor the least as it is a lot of work and there is no guarantee that I’ll cover all cases.
I’d appreciate it a lot if users of chemmacros could give me some feedback (e.g. below in the comments) what way they would favor! Or do you see another option on how to procede? Any thoughts are greatly appreciated!
Picture: © Thorben Wengert/pixelio