Version Numbers in Module/Framework Packages

[jrawbits]

People need to pay attention to the Version numbers in Package DESCRIPTION files. For ease in resolving conflicts when merging and rebasing, I'd like to suggest that we do a new package versioning scheme where we would update the DESCRIPTION with something like:

Version: YYYY.mm.dd

Then it would be incumbent on anyone who is updating a package or the framework to touch the Version in the description. Going forward, I'm disinclined to merge package updates that do not have a unique version compared to the HEAD of development.

[jrawbits]

It may be hopeless to require this (having tried to do it in my own workflow and failing miserably). But the ambition of examining the package DESCRIPTION file any time a proposed change is made in a package for current Version number would be good. There's a general problem of making even trivial fixes go through pull requests (I'm guilty even this very day of not having done that to close a couple of small issues) and having a ritual protocol of creating a local branch from the pull request, checking DESCRIPTION, rebuilding the module (and demanding it pass R CMD check without errors, warnings or notes see #26) , and running some test model that uses that module so we can see everything still works. Automating that would be sweet. I'll drop some ideas in the Discussion.

[jrawbits]

Here's another idea: get the build-module.R script to lift the module version from VEComponents.yml (if present) and force it into the package DESCRIPTION file prior to building the package. The Github might have the version in the package, but the "real" number that appears on release is dropped in from the master configuration when the package is moved over to the src folder for building. That would keep all the versioning in one place (including for visioneval and VEModel themselves).