Sorry, I was off the grid last week. But yes, in the past we used to use the Affects Versions, Fix Versions as described in conjunction with the 'Status' field. I would suggest committers to update the bug item to 'Fixed' when the commit is made to SVN and 'Close' the issue only after the release has been made and verified.
Regarding what goes in 3.0-incubating, I would suggest even making it as simple as possible (i.e. no critical logical/functional changes or bug fixes other than repacking to org.apache.). And put everything else into an 3.1-incubating release... I created the current Jira items quickly just so that we would not forget them, but I'll update them to later today to better reflect this. If anyone needs write access, feel free to create a Jira account and let us know your id and we could add you to the project as it's a separate auth than people.apache.org. --Pei > -----Original Message----- > From: Mattmann, Chris A (388J) [mailto:[email protected]] > Sent: Friday, September 07, 2012 6:53 PM > To: <[email protected]> > Subject: Re: release plans? > > Hey Steve, > > On Sep 7, 2012, at 9:40 AM, Steven Bethard wrote: > > > On Sep 7, 2012, at 6:30 PM, Mattmann, Chris A (388J) wrote: > >> On Sep 7, 2012, at 4:07 AM, Steven Bethard wrote: > >>> Also, does Jira let us mark the release that we plan to fix an issue by? I > didn't see any way of doing that. If we could do that, it would be an easy > query to find out what needs to be done for what release. > >> > >> Yep, you just create upcoming release versions, then set the "Fix > >> version" attribute for the issue to that version. > > > > Ok, I thought about setting the "Fix version", but that looked like the > version in which it actually got fixed, not the version in which we intend to > fix > it. But I guess eventually those should be the same, so it probably does make > sense to use that for both. > > > > Yep "Fix version" means version you intend to fix in (or the actual version > it's > fixed in): one and the same. "Affects version" usually is listed in the > situation > that the bug is discovered with a particular version *after the fact* that is, > after it was released. > > Cheers, > Chris > > > On Sep 7, 2012, at 4:50 PM, Masanz, James J. wrote: > >> I propose the following: > >> > >> 2.6-incubating > >> CTAKES-7 Pre-Migration- Update/Migrate current cTAKES documentation > >> CTAKES-13 Pre-Migration- Create cTAKES 2.6 release (what would have > >> been 2.6 in SF) > >> CTAKES-14 TimeMention is missing feature for what is being manually > annotated as "class" > >> CTAKES-19 ctakes constituency parser does not generate function tags > >> CTAKES-24 extraneous jars in cTAKES 2.5 > >> CTAKES-33 Add Relation Extractor > >> CTAKES-36 remove generated types from source tree > >> CTAKES-42 user guide - Note that test1.xml uses CDA not plaintext AE > >> > >> 3.0-incubating > >> CTAKES-12 Upgrade to cTAKES components to latest Lucene version. > >> CTAKES-16 use uimaFIT's selectCovered() instead of UIMA's subiterator > >> CTAKES-18 add XxxxEntity|EventMention types for other NEs similar to > >> MedicationEventMention > >> CTAKES-25 retrain rest of models using OpenNLP 1.5 > >> CTAKES-27 Upgrade cTAKES dependencies/libraries > >> CTAKES-28 Externalize dictionarylookup/UMLS password to password file > >> or variable > >> CTAKES-30 Maven integration of cTAKES components > >> CTAKES-31 constrainToWindow assumes tokens are not sorted > >> CTAKES-32 dictionary lookup creates new LookupTokens many times > >> CTAKES-35 SyntaxAttributeCalculator.java hardcodes file names > >> CTAKES-38 Orange book is not the most recent > >> CTAKES-39 Upgrade LVG to a later version > >> CTAKES-44 Tokenizer does not handle Windows-style newlines > >> CTAKES-47 codes and OUI in > CreateLuceneIndexForSnomedLikeSample.java > >> CTAKES-48 negation annotator - Sentence type used in code not in > >> descr > >> CTAKES-50 Remove UIMA Deprecated references in Annotators > >> CTAKES-52 Context sensitive tokenizer misses certain kinds of time > >> expressions > >> CTAKES-53 move UMLS out of Apache distribution > >> CTAKES-54 rename packages to org.apache.ctakes > >> CTAKES-55 rename modules consistently > > > > > > This all looks basically good. My only concern would be CTAKES-53 - don't > we have to remove UMLS to be able to release from Apache? My > understanding was that otherwise we can't release due to licensing conflicts. > > > > Steve > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: [email protected] > WWW: http://sunset.usc.edu/~mattmann/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++ > Adjunct Assistant Professor, Computer Science Department University of > Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++
