- OK: on Red Hat Linux downloaded & unzipped uima-as-2.9.0-bin.zip
<https://dist.apache.org/repos/dist/dev/uima/uima-as/2.9.0/RC1/uima-as-2.9.0-bin.zip>
- OK: followed README instructions to
          > setup environment variables
          > adjust examples paths
          > start broker
          > deploy & utilize async service (MeetingDetector)
          > ........Completed 8 documents; 17165 characters
          > Time Elapsed : 2553 ms
- OK: README & Release Notes
- OK: License & Notice
- OK: cursory inspection of Jira Report
- OK: cursory inspection of uima_async_scaleout.html

+1 Approve the release

Lou.

On Mon, Nov 28, 2016 at 1:53 PM, Jaroslaw Cwiklik <cwik...@apache.org>
wrote:

> - Signatures (md5, sha1) - OK
>
> - Built from source - OK
>
> - jira-report - OK - the list is not sorted on a Key (JIRA#)
>
> - README & Release Notes- OK
>
> - License & Notice - OK
>
> - UIMA-AS Eclipse plugins - OK
>
> - UIMA-AS Eclipse example runtime configurations - OK
>
> - Example scripts from /bin: startBroker, deployAsyncService,
> runRemoteAsyncAE - OK
>
>
> +1 Approve the release
>
> - jerry
>
> On Wed, Nov 23, 2016 at 2:01 PM, Burn Lewis <burnle...@gmail.com> wrote:
>
> > But what is the purpose of this test?   Currently it expects the major
> > version numbers to match, and prints a misleading error message if they
> > don't.  Are we sure that UIMA-AS 2.9.0 will work with any V2 UIMA?  Or
> > should the test be for the version of core UIMA that UIMA-AS includes,
> and
> > has been tested with?  Perhaps that would be too restrictive since it may
> > work with older or newer versions, so should we just generate a warning
> if
> > only the major versions match?
> >
> > Burn
> >
> >
> > On Tue, Nov 22, 2016 at 4:50 PM, Jaroslaw Cwiklik <uim...@gmail.com>
> > wrote:
> >
> > > I did find a "small" bug in the code that logs a message when versions
> > > don't match.
> > > Its only effecting logging in this particular case where I chose v
> 3.0.0
> > as
> > > the next
> > > version for UIMA-AS.
> > >
> > > I think the RC1 should not be taken down for this reason. In RC1 both
> > uimaj
> > > and
> > > uima-as are at 2.9.0 and auto generated code (UimaVersion &
> > UimaAsVersion)
> > > are
> > > correct.
> > >
> > > Ultimately its up to you testers to decide if this is critical bug
> > > deserving -1.
> > >
> > >
> > > Jerry
> > >
> > > On Tue, Nov 22, 2016 at 4:21 PM, Marshall Schor <m...@schor.com> wrote:
> > >
> > > > Ah - OK.  So you're saying, this RC is (possibly) good, and we should
> > go
> > > > ahead
> > > > and test it, etc., and you'll fix the "next" release RC later, right?
> > > >
> > > > -Marshall
> > > >
> > > >
> > > > On 11/22/2016 3:57 PM, Jaroslaw Cwiklik wrote:
> > > > > Marshall, this is caused by me choosing next version to be
> > > 3.0.0-SNAPSHOT
> > > > > when doing
> > > > >
> > > > > mvn release:prepare -DautoVersionSubmodules
> > > > >
> > > > > The UIMA-AS code does this check:
> > > > >
> > > > >       if (UimaAsVersion.getMajorVersion() !=
> > > > UimaVersion.getMajorVersion())
> > > > > {
> > > > >
> > > > > I will choose 2.9.1 as the next version when doing RC2 :)
> > > > >
> > > > > Jerry
> > > > >
> > > > > On Tue, Nov 22, 2016 at 3:40 PM, Marshall Schor <m...@schor.com>
> > wrote:
> > > > >
> > > > >> hmmm, the latest Jenkins build is showing 4 test failures?
> > > > >>
> > > > >> -Marshall
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>

Reply via email to