Define process of adding supported meta-information files

[Tapppi]

#76 opened the discussion on supporting config.xml for cordova versioning. The process for extending the support of standard-version for different meta-information files/formats has not really been had as far as I know. In my opinion the cordova support is fine, and it would be cool to support different meta-information files, since the possibility of drawbacks (e.g. some other build system using a config.xml with a different format) seem slim.

/CC @bcoe @stevemao @nexdrew @tomchentw

[Tapppi]

Following up on this, bower support landed in #148 and cordova versioning is waiting for someone to finish up #76. I think @bcoe did a good job of getting this started with the bower support and it's now more about refinement and documentation. I'll keep this open at least until #76 lands as it will be a good proving ground for the new structure for adding support for different formats and should start solving the problem of different file formats (.xml|.json).

[bcoe]

@Tapppi definitely love the idea of getting #76 over the finish line, might be worth picking up ourselves.

[mfilotto]

Same for other programming languages or even just based on git tags #165

[lancecaraccioli]

I'm looking for a more generic hook into the bump flow. I'm currently using npm-version which provides the new version number in the preversion step so that I can run scripts which tag the source (by generating version.js) and README files. Wouldn't this be a viable solution for other libraries to extend the workflow? Or does this already exist and I missed it?

[bcoe]

👋 the library has been refactored quite a bit since this thread was opened, making it easier to bump generic build files.

please feel free to open PRs that add additional file types.