product-os / versionist

Flexible CHANGELOG generation toolkit that adapts to your commit conventions
44 stars 15 forks source link

Could provide sample configs for other languages #84

Open lurch opened 7 years ago

lurch commented 7 years ago

This repo currently provides a versionist.conf.js tailored for NodeJS (npm) projects, which is the tech-stack used by many resin.io projects. However there are also some resin.io projects using other languages, like go, rust or python (etc.). To help with versionist-standardisation across all resin.io projects, it might be useful if this repo also provided sample config files for the other tech-stacks we use.

Suggested in: https://github.com/resin-io/edge-node-manager/pull/175 (which possibly provides an example of where this would have been useful).

Tech stack Manifest file Versionist support
NodeJS package.json / npm-shrinkwrap.json / package-lock.json ✓ (but see #103 )
Python setup.py / __init__.py ✓ ( #100 )
Rust Cargo.toml / Cargo.lock ✓ ( #85 , #97 and #104 )
Go ??
Ruby ??
Keyframes keyframe.yml
lurch commented 7 years ago

And I've also just noticed that there are projects like https://github.com/resin-io/leech where it's just a bunch of shell scripts, so there's no "package manifest" file to update.

lurch commented 7 years ago

Thinking a bit more about this, and prompted by https://github.com/resin-io/resin-base/pull/33 and https://github.com/resin-io/leech/pull/9#pullrequestreview-48356740 and https://github.com/resin-io/edge-node-manager/pull/119#pullrequestreview-48359876 ...

Originally, every usage of versionist required there to be an accompanying versionist.conf.js file in the repo, telling versionist how to operate. But then people realised that this meant that all the different resin.io repos that used versionist, would gradually end up over time with slightly different versions of versionist.conf.js, and keeping them all in sync would become impossible. So the decision was made that a "resin.io standard" default versionist.conf.js should be included within versionist itself, so that each repo no longer needed its own config file, and thus they'd all be kept in sync automatically as the version of versionist got updated. This all works fine for repos using NPM, as the default versionist.conf.js inside versionist includes updateVersion: 'npm', as this is the tech-stack used by most of the resin.io repos.

However now that versionist and VersionBot are being deployed more widely over more and more resin.io repos, there are some repos where updateVersion: 'npm' isn't appropriate, and so these repos have to go back to having a full local copy of versionist.conf.js (so far I'm aware of leech, edge-node-manager and resin-base, but I'm sure there are probably others). This means we're back to the situation we were trying to avoid, where we'll end up with different versionist.conf.js files in different repos, gradually drifting more and more out of sync. AFAICT, in order to fit in with the "resin.io standard" way of working, most of the time the majority of the fields in versionist.conf.js in these non-NPM repos will be identical to the built-in config, with the only exceptions probably being editVersion: or updateVersion:. So I wonder if there could be some kind of "overlay config file" that these non-NPM repos could use, containing just the editVersion: or updateVersion: fields, and then versionist would use all the "resin.io standard" fields from its built-in versionist.conf.js, only 'overriding' those fields specified in this "overlay config file" ?

Ping @hedss @lekkas @brownjohnf @josephroberts @CameronDiver @imrehg

brownjohnf commented 7 years ago

There is now support for presets in versionist itself, which is probably the right way to go. What I'd like to see is a way to override only certain behavior/functions from the versionist config file without having to include the entire exports object.

lurch commented 7 years ago

LOL, snap! ;)

lurch commented 6 years ago

See also #100

lurch commented 6 years ago

https://github.com/resin-io/versionist/issues/82#issuecomment-301472179 also provides another example of where versionist needs to be able to bump a version in a file-type not covered above.

Given the awesome work @majorz did in #104 I wonder if a lot of the above file-types not already handled by versionist would be covered by e.g. a quotedPatternReplace preset, which had targetFile and targetPattern parameters (both of which would be mandatory). This means the meta-resin version-bumping needed by @agherzan could be handled by e.g.

updateVersion: {
    preset: 'quotedPatternReplace',
    targetFile: 'meta-resin-common/conf/distro/include/resin-os.inc',
    targetPattern: 'DISTRO_VERSION = '
}

in versionist.conf.js, and then the replace function that @majorz added would be called like:

replace(
    'meta-resin-common/conf/distro/include/resin-os.inc',
    /(DISTRO_VERSION = )("|').*?\2/,
    '$1$2' + cleanedVersion + '$2',
    done
);

and this would then change e.g. DISTRO_VERSION = "2.9.7" to DISTRO_VERSION = "2.9.8" in meta-resin-common/conf/distro/include/resin-os.inc, which would allow meta-resin to start using versionist. (Ah! At least without having to use exec... https://github.com/resin-os/meta-resin/blob/master/versionist.conf.js#L34 ).

If this works, it also means that the Python support @nghiant2710 added in #100 would be functionally equivalent to:

updateVersion: {
    preset: 'quotedPatternReplace',
    targetFile: '__init__.py',
    targetPattern: '__version__\s*=\s*'
}

:wink: (of course I'm not suggesting that the initPy preset should be removed, just showing the flexibility that a quotedPatternReplace preset might have)

Maybe the quotedPatternReplace preset would also need an optional targetPatternFlags parameter, to allow e.g. the /g and/or the /m regex modifiers to be specified?

cc @hedss

hedss commented 6 years ago

@lurch I think that's actually a really good idea (and yes, I think the ability to specify flags should also be included).

lurch commented 6 years ago

@hedss Cool, just created #110