Release cycle and automated upgrades?

[jchodera]

As the cookiecutter is continually being updated, it might make sense to start cutting releases so that projects using the cookiecutter have a clear cookiecutter version they are based on, and to think about how to provide a semi- or fully automated upgrade path to update repos that use the cookiecutter to stay current with the latest best practice.

[dgasmith]

Definitely agree on the versioning. We have this currently, but it is a manual process that doesn't reflect minor bumps. I have been thinking about making a dev branch that all PRs go to and then we merge into master with a version bump. Automated ways may be possible, but likely more of a hassle than they are worth.

We have discussed semi automated upgrades in the past and have determined they are outside our current scope. Automated upgraded paths that we have found are either very fragile or would require greater control over how the project works in the future. The latter would be similar to conda-forge builds where the only file you could edit would be a YAML. I am not sure how well people would respond to this.

[jchodera]

We have this currently, but it is a manual process that doesn't reflect minor bumps.

Weird! I don't see anything on the releases page!

[dgasmith]

Cookiecutter doesn't work well with releases, we update the package JSON info to reflect the version in the README here and here.

We could try recommending something like:
cookiecutter https://github.com/MolSSI/cms-cookiecutter.git --checkout stable

This seems messier than the current way of operating however.

[jchodera]

A major goal of encouraging standardization of best practices is to make it easier for individuals or groups within CMS to collaborate by structuring packages and testing automation in a similar way. If each deployment is slightly different because there are no major releases, and upgrading to the latest version is a difficult manual effort, that seems counter to this goal.

Is there some middle ground that might be good here, rather than having each cookiecutter invocation pick up the very latest incremental change from master, such as clearly-labeled quarterly releases?

[dgasmith]

Agreed, hence my suggestion we need a dev and master branch so that we can pool changes into a dev branch. Travis to GHA is our first fundamental change since we moved to the conda infrastructure.

@loriab @mattwelborn @janash @Lnaden We should think carefully here, any thoughts?

[loriab]

versioning the cms cookiecutter seems the straightforward, if awkward, part. changing the cookiecutter-generated files (that hopefully the project has further customized) is more challenging. this is a thread of others with the same problem. anyone ever tried a solution for the update part?

[dgasmith]

The main issue around automated updates is that we need to force a separation between operations and metadata. This is helped quite a bit by the conda-envs, but custom modifications to a travis build like build matrices or custom lint checks prevents an easy conversion. You can of course parse the YAML and regenerate new versions, but it adds quite a layer of complications.

I do not believe the MolSSI team has the bandwidth to tackle it at the moment, but I can lay out the issues and potential pathways if someone would like to attempt it.

[loriab]

As an easy stopgap that doesn't involve complicated git, I wonder if the compare address from time of cookiecutter checkout could just be stamped into the generated project like so: Check https://github.com/MolSSI/cookiecutter-cms/compare/67cf...master periodically for useful updates. It's a manual update but easy for a beginner to understand.

[jchodera]

What if we added a check at the beginning of the travis testing that pops up a warning if (significant?) cookiecutter updates in master are available and prints (manual) upgrade instructions if so? That would at least allow folks with nightly builds know when they should think about (manually) upgrading?