Another approach (copying how the Eclipse and other web sites do this), would be to have a link on the main download page to another, archive download page, which would be an organized web-page to the older releases. (as opposed to just saying go find the artifact you want from this general spot on archive.apache.org).
-Marshall On 5/27/2015 1:41 PM, Marshall Schor wrote: > 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 >> >> >
