-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tag modulesync_config 'releases' #81
Comments
👍 for tagging, but maybe not vX.Y.Z because this always reminds me on semantic versioning, what about date tagging like YYYY-MM-DD? |
We can still have 'semantic' versioning but only bump the minor version number, which implies that breaking changes can always happen between versions. eg. 0.1.0, 0.2.0...0.40.0 etc . I find dot numbering easier to remember than dates... |
You definitely can't communicate "breaking changes" in timestamps.
|
ah right, 👍 for vX.Y.Z |
Do we care about modules being on the same version of modulesync_config? Honest question. Modulesync is ad-hoc as-is. |
I think modulesync should be a bit less ad hoc, actually, and enforced
across modules when things change. Until then, inserting a comment
somewhere in .sync.yml or something with the version so you're at least
aware of when a module was last synced would be incredibly helpful. We had
an issue with `puppet/archive` recently where it wasn't apparent when or
what version it was synced to and it would have helped us a bit to know
that.
|
Alright, I've pushed a tag 0.1.0 for the current state of master. Let's see how this works in practice. |
If we perform modulesync to get modules to a 'consistent' baseline, we are currently making changes to modulesync_config quite often and therefore the 'baseline' is changing quite a lot depending on the commit.
Start tagging modulesync_config (ignore Semantic versioning) so that we can then do things like eg. "Modulesync with modulesync_config v0.0.5"
The text was updated successfully, but these errors were encountered: