WG Hangout 2013-06-25
1. Discussion of Andrew’s Release Guide
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.