0.4.0 release notes

[garlick]

Here's a stab at release notes for a 0.4.0 release:

• Scalability improvements:
  • don't store broken-down hwloc topology in the KVS (resource-hwloc: do not walk topology by default? #716)
  • route rank-addressed requests via TBON (use TBON not ring network for RPCs #689)
  • streamline matchtag handling (Tagged response fastpath #687)
  • keep active jobs in a separate KVS namespace from "archived" jobs (sqlite db grows unreasonably large when running many small jobs #609)
• New features:
  • implement PMI-1 simple server in wrexecd (implement PMI-1 wire protocol in wrexecd #706)
  • add skeletal PMI-2 library (based on PMI-1) (Improve PMI tracing and support PMI-2 subset for OpenMPI #747)
  • make libflux-optparse.so available externally (expose optparse API publicly #702)
  • asynchronous KVS fence and rewritten fence path in KVS module (implement async kvs_fence() call #707, kvs.err[0]: XXX encountered old commit state=4 fence_name=lwj.1.0 #729)
  • flux-cron, a cron/at-like service (implement crontabs #626)
  • flux-proxy and ssh:// connector (flux-proxy command #645)
• Other changes:
  • Use RFC 5424 log format for internal logging, not ad hoc JSON (Logging cleanup #691)
  • Add wreck lua.d MPI personalities (move MPI/PMI environment variables to wreck plugin(s) #669, small tweak to get intel MPI working on RHEL 7 #743, Improve PMI tracing and support PMI-2 subset for OpenMPI #747)
  • Improved command line for launching flux from slurm/flux (better user interface for launching flux under flux/slurm #658)
  • Assorted code cleanup.
  • Automatic github release upload on tags (travis-ci: Add more recent compilers, small fixes, and Caliper testing #744)
• Testing:
  • Print backtraces for any core files generated in travis-ci (Enable coredumps on travis-ci #703)
  • Add cppcheck target to travis-ci (Add cppcheck run to travis build matrix #701)
  • configure --enable-sanitizer for AddressSanitizer, ThreadSanitizer (AddressSanitizer support #694)
  • caliper based profiling (Support Caliper based profiling #741)
  • improved test coverage
• Deprecations
  • Sophia content backing store module (Drop sophia content store back end #727)
  • mrpc KVS based muti-RPC interface (use TBON not ring network for RPCs #689)
  • ZPL config file (simplify Flux environment handling, drop config file support #674)
  • Ring overlay network (use TBON not ring network for RPCs #689)

[grondo]

Thanks!

Do any of the other items on 0.4.0 milestone still belong there or should we punt them to 0.5.0?

Should we add @trws's Caliper tracing support to the milestone for 0.4.0? I was working on getting Caliper building in travis so we can test it, but the testing could be added as a future commit. For now I could publish my fork of @trws's branch and we could work on that as a new PR?

[garlick]

I was just (slowly) visiting each of the milestone items and was going to comment on each. Stand by.

I think we ought to get caliper support in. Your plan to create a new PR makes sense to me.

This above was just intended as a start and was put together pretty quickly. I always seem to suspect I have more to say about my own work than that of others in these things so please comment if I've left gaps or thin areas.

[grondo]

It looked pretty complete to me, I usually just list the merge commits to double check

git log --merges 0.3.0..HEAD

At one point we had talked about having special tagged commit messages (required for PRs?) that could emit a line of Release Notes. Something like that will be required to automate the process.

[garlick]

Just updated the release notes above with

• pmi2 library
• caliper support
• automatic github release upload on tag

[grondo]

Great! I think the process for a release will now be two steps:

• Create PR NEWS.md: Update for release v0.4.0, with heading like

  flux-core version 0.4.0 - 2016-08-11
  ------------------------------------
  

• After PR is merged, tag v0.4.0 (I realize we aren't using the "v" prefix, that seems to be common and allows version tags to be listed quite easily git tag -l | grep ^v -- any reason not to switch to it? I'm actually not feeling strongly either way.

• Push the tag, which should cause the release tarball and link to NEWS.md file to be added to the GitHub release. If it works the first time I'll actually be surprised.

[garlick]

I think 0.4.0 is ready once your coverage PR is merged. I'll get a PR going for NEWS.md.

[garlick]

On the "v' prefix to tags: I also don't mind. Should I add a patch to the NEWS PR to snip "v" off the front of the result of git describe so that it won't appear in PACKAGE_VERSION, the dist tarball, etc?

[garlick]

We've tagged, so closing this.