On 5/24/2013 4:10 PM, Richard Eckart de Castilho wrote: > 2.4.0C - I closed that release now after closing the last issue in it. > Apparently, nothing had to be done there anymore. > >>>> 2.3.1 -> merge issues into 2.3.1SDK? >>> hmmm, I guess these issues would need to be investigated, one by one? If >>> all >>> of them get classified into some other version, and the "2.3.1" ends up >>> being >>> empty, then I think it's OK to remove it. >> The issues in 2.3.1 are all closed, except one that is resolved [1]. >> >> Three of the issues are "build, packaging and test" and seem to be long to >> 2.3.1SDK (released) >> >> The other issues are "addons" or "Sandbox" issues, that appear to belong >> into 2.3.1Addons (released) > This will stay open indefinitely unless we come to a decision. Here are the > options: > > 1) just mark as "released" > 2) reopen issues, reassign them to 2.3.1SDK and 2.3.1Addons, close issues, > then delete the version > > I vote for 2. +1 > >>>> 2.3CE -> the CAS Editor is part of 2.4.0SDK, so this can probably be >>>> marked as "released"? >>> I think these issues need to be investigated, one by one, and perhaps >>> assigned >>> to their proper versions. Then, if 2.3CE ends up "empty", it can be >>> removed I >>> think. >> The issues in 2.3CE are all closed. >> >> 2008-08-12 - The last separate CasEditor-2.2.2 release seems to have been >> this day (UIMA-1141). >> >> 2009-05-28 - the CAS Editor stuff has been integrated into uimaj (UIMA-1360) >> >> 2010-01-26 - release UIMA 2.3.0 (includes CAS editor) >> >> The highest issue number in the 2.3CE version is UIMA-1351 (before the move >> to uimaj). It appears that these issues should be relabeled "2.3.0SDK". >> Unfortunately, there is no such version, the next one in Jira would be >> "2.3.1SDK". How do you suggest to proceed? > Same here. > > 1) just mark as "released" > 2) rename the version to 2.3.0SDK, then mark a released > 3) reopen issues, reassign them to 2.3.1SDK, close issues, then delete the > version > > I vote for 2. The 2.3.0 version of UIMA was while it was in the incubator. It can be found in the JIRA versions - click on versions, and then "manage versions" in the upper right corner. You can find it under the name "2.3" with the description "Version 2.3-incubating". It's marked "released" as of 26/Jan/10.
Because these Jira's are for issues that were fixed and included as part of this release, I would reclassify these Jiras as fixed in "2.3". > >>>> 2.2C -> 2.4.0C has been released meanwhile, so this can probably be marked >>>> as "released"? >>> Looking in archive.apache.org/dist/incubator/uima/source - I don't see that >>> uima >>> CPP 2.2 was released. There was a 2.2.2 that was released, though. >> The issues in 2.2C are all closed. I doubt there will ever be another 2.2C >> release, since we have releases with higher versions already. It doesn't >> make sense to keep this issue around unreleased. The easiest thing would be >> to mark the release as "released". Moving the issues to another release, >> e.g. 2.2.2C would mean reopening, reassigning, resolving and closing each of >> them. Unfortunately, the Apache Jira is not configured to allow the editing >> of closed issues. > Same here. > > 1) just mark as "released" > 3) reopen issues, reassign them to 2.2.2C, close issues, then delete the > version > > I vote for 1. I would suggest "1" as well, but I would change the text description to indicate what's going on. Something like: not released as 2.2.2C, but released as part of 2.4.0C. The main idea is to have our "records" be self-describing, and not dependent on anyone remembering things :-) -Marshall > > Do we need formal votes here? After all, we are not talking about "real" > releases, only about cleaning up the Jira clutter. > > -- Richard > >> [1] >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.3.1%22%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC >> >
