WG Hangout 2013-06-25

Agenda

1. Discussion of Andrew’s Release Guide

2. Beer!

Minutes

AJ: Not clear what doing a release means for this WG, hence created this release doc.

TK: Does a release mean just the core modules?

AJ starts going through document...

SV: No notification of pre-release or RC in the version number.

AJ: Change version number suffix to stage notification

AJ: Modify existing Hg tag names?

All: No, just adopt the right thing for the next release

AJ: Compatibility, API/ABI?

Ans: Not much experience with ABI compat.

AJ: Minor releases we’ll promise API, not ABI.

AJ: Bug-fixes try ABI compat, review after we get some experience.

MK: May prove to be hard.

AJ: 2 weeks between release stages?

TK: Seems fine.

AJ: Status of old Java instructions?

MK: Ralph may know more.

DH: I did the last release, following the scripts without actually running them, do the right thing but may need updating (pvIOC, pvCommon).

AJ: Move release instructions out into each module?

SV: Easier if there’s a top-level Makefile or script to build everything. Building everything separately is painful.

TK: May be clear for Base modules, hard for other modules.

AJ: Maybe make any script configurable as to which parts to include.

AJ: Don’t want to put “how to release everything” into release instructions.

TK: Document the base infrastructure, then modules on top.

AJ: Separate document.

AJ: We publish jar file, who generates them?

DH: Greg does that.

AJ: Need another role for the Java Builder...

AJ: Spread tar-file generation across the group?

MK: No, one person for each platform.

DH: I do C++, Greg does java.

MK: Java documentation lists all modules being released, C++ doesn’t have a list, needs one.

  (lists them, include note that pvIocCPP won’t be needed in future release.)

TK: pvaSrv is essential, but not part of the core released module list.

AJ: Thanks, that’s all for me.