Are bump and changelog features relevant?

[neomilium]

@ekohl and I started a discussion in #215 about this topic, so I quote my thought here:

From my point of view, whole PuppetModule class should be deleted from msync: most of us uses a local (ie. contained in each puppet module) rake task to bump its version, and for changelog more and more uses an algorithm to generate, it using github_changelog_generator...

Who use this feature these days?
Do we need to keep puppet module's specific code in msync?

[ekohl]

Perhaps it would be better to have that functionality implemented via hooks. There is also other code I would like to execute (such as puppet-lint, rubocop) that is probably too complicated for modulesync. Personally I think modulesync should be as light as possible and solve problems via extensibility. Like UNIX tools should behave.

[neomilium]

I agree.
Just for the story, I started to work on an execute command for msync first (see #199)... Even this #199 PR code is working and used by us (ie. opus-codium), I found the patches were made on top of a spaghetti code. So I started #206 which is the epic target and is currently split and parts are merged one by one (Thanks to reviewers for the help).

After #206, I will rewrote exec and push features on top of the cleaned code and we will be able to use msync as a light tool that "only" handles massive git repos and allow to apply a template to all of them.

[ekohl]

After #206, I will rewrote exec and push features on top of the cleaned code and we will be able to use msync as a light tool that "only" handles massive git repos and allow to apply a template to all of them.

That is exactly how I see modulesync.