> Is the new dep parser/SRL a new model? Or was that sentence a copy/paste
> error?
It's a copy and paste error. Feel free to update it to reflect the recent
release.
> I suggest we have a 3.1.1 release to roll in any simple bug fixes that
don't
> require much doc change at all.
I think that's a good idea. Feel free to rename the pom's.xml in trunk to
reflect the {placeholder} name.
> That will make 3.2.0 easier to release. And also provide earlier fixes to
folks.
> I also suggest having a .1 release be our typical release model - a .1
release
> for bug fixes.
The name of the future release is just a {placeholder} in the pom.xml, the
actual name gets created when the RM cuts the release/branch based on the
changes. I think cutting release should be much smoother now and we'll
probably release more often, I agree, I think we can default the name of
future release to be also an increments of a patch.
> I see advantages to having a new release manager for any .1 release, but
also
> see that for efficiency sake, it would be good to have the release manager
> for a .0 and a .1 be the same.
> I am willing to be release manager for a 3.1.1 release.
Thanks! No objections or preferences- As long as someone steps up and is
willing to do it :)..
--Pei
On Wed, Sep 4, 2013 at 11:28 AM, Masanz, James J. <masanz.ja...@mayo.edu>wrote:
>
> Is the new dep parser/SRL a new model? Or was that sentence a copy/paste
> error?
>
> I think the following line should be removed
> - New Standardized Clinical Element Model Instance Template population
>
> And instead of new regression testing component, it should be 'enhance the
> regression testing component'
>
> I suggest we have a 3.1.1 release to roll in any simple bug fixes that
> don't require much doc change at all.
>
> That will make 3.2.0 easier to release. And also provide earlier fixes to
> folks.
>
> I also suggest having a .1 release be our typical release model - a .1
> release for bug fixes.
> I see advantages to having a new release manager for any .1 release, but
> also see that for efficiency sake, it would be good to have the release
> manager for a .0 and a .1 be the same.
> I am willing to be release manager for a 3.1.1 release.
>
> -- James
>
> -----Original Message-----
> From: dev-return-1947-Masanz.James=mayo....@ctakes.apache.org [mailto:
> dev-return-1947-Masanz.James=mayo....@ctakes.apache.org] On Behalf Of Pei
> Chen
> Sent: Tuesday, September 03, 2013 4:12 PM
> To: dev@ctakes.apache.org
> Subject: [DRAFT] [REPORT] Apache cTAKES Sept 2013
>
> [DRAFT]
> Apache cTAKES (clinical Text Analysis and Knowledge Extraction System) is a
> natural language processing (NLP) tool for information extraction from
> electronic medical record clinical free-text.
>
> Issues:
> There are no issues requiring board attention at this time.
>
> Releases:
> Last release was created on 2013-09-06 (ctakes-3.1.0) <pending rc3 vote>
>
> Development:
> During the last quarter, the committee released 3.1.0 of cTAKES.
> The committee is actively working and planning for the future release 3.2.
> Some of the planned code changes include:
> - New Dependency Parser/Semantic Role Labeler
> - New optional Clear-Based Parts Of Speech Tagger
> - New Standardized Clinical Element Model Instance Template population
> - New regression testing component
> - Various bug fixes and code enhancements tracked Jira
>
> Community:
> We have added John Green as a committer and PMC member since last report.
> dev mailing list subscribers count: 81 (+13 since last report)
> user mailing list subscribers count: 69 (+11 since last report)
>
