I
- do my very best to not change APIs or functionality after they've been in the public as production-ready without extremely good reason
- always (do my best to) leave the existing behavour as default, and any change to the product must be acknowledged and implemented consciously by the user (ie. no "it worked well yesterday!")
- am seriously pedantic about my documentation for all of my software, so any new config/param etc would certainly be clearly documented
- maintain a robust Changes log for all of my software, so both users and developers can easily find when somethings been added
- keep commits as tight as possible; a commit includes (for the most part) only details surrounding a single piece of something (in this case, an add of a new config var or new command line flag
- mostly keep commits lined up with an issue, so it's easy to track everything part of the change (ie. I generally create an issue for any change I see, need or want to make)
So, I've got the following options to ponder thus far. Possibly just one, some or all:
- config var for global
- new flag for individual install berrybrew install x.xx -win_home (the name of the flag is irrelevant at this time)
- possibly a new top-level berrybrew command (eg: berrybrew home [windows|portable]) (where the option can be left out and the command alone will print out what the current setting is, and perhaps even make it take another arg, a specific version of Perl to operate on an individual instance if desired) (Again, name is more or less irrelevant here. Suggestions welcome).
Note to self (I'm using this as a reference from the issue itself): If we're to go with an option where the portable module can be disabled/enabled, we'll have to create a new storage directory in the root dir, put the file(s) in there, and somehow associate each pm file with the instance it came from.