You can use the Fix Versions field as you stated but someone has to create the 2.6, 3.0, etc versions. If you did patches in the future, no problem, you can create say a 3.0.1.1 version if you want.
Thanks Troy -----Original Message----- From: [email protected] [mailto:[email protected] ] On Behalf Of Masanz, James J. Sent: Friday, September 07, 2012 9:51 AM To: [email protected] Subject: RE: release plans? I think we need 2 issues opened regarding the type system. I will do that today. One for things that are additions and won't impact current users, and another for things that require refactoring and could affect current users, such as the fix to be creating an (instance of a subclass of) Event for a disease/disorder etc instead of an (instance of a subclass of) Entity. To mark the release that we plan to fix an issue by, perhaps we could use the "Fix Version/s" field. Or does that normally include the version that a patch is released for (if we ever create patches). 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 Regards, James Masanz > -----Original Message----- > From: ctakes-dev-return-323- > [email protected] [mailto:ctakes-dev-return- > [email protected]] On Behalf Of Steven > Bethard > Sent: Friday, September 07, 2012 6:07 AM > To: [email protected] > Subject: release plans? > > So I know we're still waiting on Apache to upload the code to SVN > (https://issues.apache.org/jira/browse/INFRA-5079) but perhaps we could > already be talking about what our upcoming release plans look like? Here are > several things that I know are in the pipeline, but I don't know which release > they're planned for: > > * Move UMLS out of Apache distribution > (https://issues.apache.org/jira/browse/CTAKES-53) > * Rename packages to org.apache.ctakes > (https://issues.apache.org/jira/browse/CTAKES-54) > * Rename modules consistently > (https://issues.apache.org/jira/browse/CTAKES-55) > * Change build infrastructure to Maven > (https://issues.apache.org/jira/browse/CTAKES-30) > * Update UIMA type system so that it is possible to load SHARP annotations > (James, could you and Stephen Wu file an issue for this with appropriate > details?) > > My current guess is that the release plan looks something like: > > 2.6-incubating: CTAKES-53 > 3.0-incubating: everything else > > Is that right? Are there other open issues that have to be addressed before > 2.6-incubating? > > 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. > > Steve
