connect toEPICS V4 Telecon for August 6th 2013

Agenda for August 6th 2013

1. Release numbering (again): AJ, GW

  - V3 convention says ".0" = development release

  - Can we adopt this (change numbering again)?

2. Packaging and publishing the release candidate: GW

  - Packaging by scripts.

  - Implementing in Cloudbees, can we build packages automatically?

  - Discuss whether there should be snapshot tars.

  - Can automatic packaging be extended to C++ modules.

  - Finalize getting release candidate tars.

3. Ev4Buildtracker.xls: GW

  - Status of Windows, RTEMS and VxWorks targets?

  - Adding Java modules

  - Add status table of ALL EPICS V4 modules to website

    telling visitors what's in 4.3, what isn't and why.

4. Comments on pvData-md: DH, MK, MD

5. Discussion on pvDatabase: MK

Minutes

Present: AJ, BD, GW, MS, SV, TK, MK, NM

Scribe: SV

Chair: AJ

1. Release numbering (again): AJ, GW

  - V3 convention says ".0" = development release

  - Can we adopt this (change numbering again)?

AJ: http://semver.org/ has spec on versioning that is used by open source. Perhaps that is the way to go.

GW: Problem is module vs release version. For module we could have something that is different from semver.org (which we should use for collection)

AJ: disagrees. semver.org makes perfect sense for modules

GW: overall version number is for collection. modules may not even have to change and their version numbers would have to change

AJ: module does not have to go through the whole process

GW: does collection have “pre” etc?

AJ: collection specifies major and minor version, specifies “pre”, etc. The individual module can go through the release cycle independent from collection

GW: this was described in the doc I sent last week:

http://epics-pvdata.sourceforge.net/ReleaseProcessforJava.pdf

GW: goes through the above doc

AJ: each module need full dependency info according to this doc, but it also needs to be able to have compatibility info

GW: this relates to automated releases

GW: module numbers should be such to allow automation.

AJ: semver.org does that

AJ: semver rules apply to individual modules

GW: if numbering scheme is objective, I’m fine with it?

AJ: zero means development, 4 is prefix

AJ: individual modules have 0 at the head (no fixed api)

GW: major cannot mean changes to api

AJ: clarifies semver scheme

GW: betaness is the same as API-ness in this scheme

GW: but that is not necessariliy the same

AJ: beta should not appear in the version number; zero means unstable software

GW: epics4 is beta, easyPVA is beta, pvAccessJava is not beta

AJ: once we decide that stuff is stable, we will release version 4.1...

GW: gives example for API change

***************

GW: girlfriend issues... :-)

***************

AJ: we have no experience with ABI compatibility yet; this is more at the minor level than the major stuff

GW: changing api is common, breaking abi is rare (requires recompile of things built above)

GW: in c++ a change of overloaded entry point may change abi (MD words)

AJ: epics never claimed abi compatibility; you need to rebuild

GW: we have bunch of modules that are interdependent; when someone changes a minor of a lower level module, it triggers recompile everything above

 AJ: lets move and continue this online

2. Packaging and publishing the release candidate: GW

  - Packaging by scripts.

  - Implementing in Cloudbees, can we build packages automatically?

  - Discuss whether there should be snapshot tars.

  - Can automatic packaging be extended to C++ modules.

  - Finalize getting release candidate tars.

RELEASE_VERSIONS

# Ev4 Release name           Hg repo name   Hg tag & Maven version

# ------------------                    ------------           ----------------------

EPICS-Java-4.3.0-pre1        pvDataJava     3.0.0

EPICS-Java-4.3.0-pre1        pvAccessJava   3.0.0

EPICS-Java-4.3.0-pre1        easyPVAJava    0.1.1

EPICS-Java-4.3.0-pre1        exampleJava    2.0.1

publishRelease:

#!/bin/bash

#!-*-sh-*-

makereleaseJars.sh -n EPICS-Java-4.3.0-pre1 -r gregorywhite

GW: process can be automated by a script if we use file like the one above

GW: whenever publish release file is changes, cloudbees could do a new release

AJ: these are details between you and RL

GW: can the automated packaging be extended to c++

AJ: should be

3. Ev4Buildtracker.xls: GW

  - Status of Windows, RTEMS and VxWorks targets?

  - Adding Java modules

  - Add status table of ALL EPICS V4 modules to website

    telling visitors what's in 4.3, what isn't and why.

AJ: GW wants updates

MS: patch for rtems included boost and resolves permissive problem; change is for pvCommonCPP

AJ: need those for rtems; we should go ahead and commit those; should they go into pre1?

AJ: it will go into next pre release; will enable rtems on APS build machine

AJ: need to update spreadsheet

******

AI on AJ: Try building against rtems 4.10 and 4.9.2, enable on APS-Jenkins if it builds.

******

MS: rtems 4.9.2 pointed by MD’s page

AJ: will check RTEMS

GW: I will add java modules

******

Action Item: GW will cleanup website w.r.t. modules descriptions; Updates with respect to what is core, what is alpha, callout dead repos (30 repos and 5 core module)

******

MD: using 4.9, would not be adverse to upgrading, just a question of time

AJ: have you tried v4 against rtems

MD: no, not primary focus; if it is not building on vxworks, will not work on rtems

GW: build tracker should be part of the release process

AJ: table on the website would be better

GW: fine

4. Comments on pvData-md: DH, MK, MD

MK: postpone this

5. Discussion on pvDatabase: MK

MK: had a new version committed, with example

AJ: do we need discussion on this?

MK: no, unless people have issues

GW: need help testing pvaSrv, compatibility with pvmanager for pre1; need to go with tags

MD: Date for release?

AJ: ASAP

AJ: should have something in august, maybe not the final release though.

MD: September?

GW: We should be able to compress this

GW: What is prompting us?

MD: I want my stuff to be merged that we decided for after the release

TK: people do not like starting to develop with software from repo directly

GW: people inside I do not get...

GW: we need to formalize the process, we cannot be muddling through stuff

GW: needs to automate this

MK: do we use mercurial branches or new repos?

GW: mercurial branches; this needs to be stone cold

AJ: mercurial plugin will handle all issues with releases; RL looking into it

MK: we do not have method in place to do the branching

AJ: we have to finish the release before we do merge

GW: progress must not be stopped...

AJ: any issues?

GW: nope

Meeting Ends 16:40 UTC