Re: looking at the patch - sorry - didn't do that (yet)... ReL UIMA C++ - does it work with UIMA 2.7.0? I believe Eddie tested that; it should be compatible.
Re: not a good reason - for the user who wants to compare performance vis an older version. I guess I think this is a good reason if it is being done to some frequency; I think the driving force for a web site should be to make it easy for users. And, we're guessing at what our users might be doing / wanting, to some degree. I also would say that I'm frequently surprised by what people are doing with UIMA, so my attempts at coming up with some scenarios probably misses some use-cases that are out there. I do agree that this can get out of hand, so removing versions older than 1 or 2 back would probably overall be an improvement (less clutter). -Marshall On 5/26/2015 5:27 PM, Richard Eckart de Castilho wrote: > On 26.05.2015, at 23:11, Marshall Schor <[email protected]> wrote: > >> I'm not sure it's really necessary to tell the reader what the reasons might >> be >> that they would want to download older releases. I think most readers who >> contemplate doing this would have their own reasons :-). >> >> Nevertheless, I'm trying to think up reasons (not sure they're "very good" >> ones). One reason might be because some segment of the population >> downloading >> things aren't ready to move to Java 7. > For me, keeping the last "Java 6" version highlighted would be a good reason, > at least temporarily. I would explicitly mention that this is the reason, > because > in my opinion everybody not restricted by the Java version should really get > the > latest version. I would also mark it explicitly as a "legacy" release, cf. > https://commons.apache.org/proper/commons-lang/ > >> Or, a user might discover what they believe to be a bug, or some other issue >> (e.g. performance) in 2.7.0 and want to revert to 2.6.0, or at least try >> 2.6.0 >> to compare. > In my opinion, that is not a good reason. I would expect that somebody > interested > enough to switch back to an older version to test for a bug should be also be > capable > of fetching that older version from the archive (or from Maven Central). > >> ================= >> >> I'm guessing (but may be wrong) that another complaint about this page is >> that >> it looks disorganized and haphazard. Perhaps another way to reorganize this >> page so it doesn't appear so fragmented, is to change the "pivot" attribute - >> that is, for instance: >> >> Have the top-level box be a bunch of links to 2nd level boxes, one per >> super-artifact. (Super-artifact is the big thing we release, such as >> uimaFIT, >> Ruta, UIMA Java framework and SDK, UIMA-AS, DUCC, etc.). >> >> The 2nd level box would be, for that "super-artifact", a list of a few of the >> last releases. So for instance, there would be a box for UIMA Java framework >> and SDK, and inside that box would be entries for version 2.7.0, 2.6.0, (and >> maybe 2.5.0). We could add a column for linking to the JavaDocs (which are >> shown in a separate section at the moment). >> >> That way, the clutter on the page would be reduced, and people could easily >> see >> the current release, and perhaps a release or 2 back-level, if needed. >> >> As I said in my previous comment, I think this web-page design is separate >> from >> where the artifacts are actually sourced from, so at anytime we could stop >> using >> the Apache mirror system for these artifacts that are older releases. >> >> WDYT? > Did you check the patch I attached to the issue? I think it changes the > organization > in the way that you describe it, except that it doesn't list old artifacts and > doesn't add the JavaDoc. > > The "weight" of the layout can still be improved if we can agree that the way > the information is grouped and organized is ok. E.g. with the proposed > layout, it becomes very obvious that UIMA C++ is stuck at 2.4.0 whereas UIMA > Java is at 2.7.0. Are these even compatible with each other? > > Cheers, > > -- Richard > >
