Maintain older versions

[podollb]

It would be great if there was a way to get access to older versions (such that when coordinating a team to all use a specific JDK for example, using sdkman for installation, it makes it tough when old versions are no longer available). So, each time a new team member joins and/or a new laptop is used, we have to use the latest JDK available (of whatever flavor we are using), and if we all want to be on the same version everyone needs to upgrade.

[rubensa]

Totally agree.

In my user case I have a base Docker image with sdkman installed. Then, for every project I have a Dockerfile based on that image that installs an specific JDK version.

The problem is when at a later time a new developer tries to build the docker image. The build fails cause the specific JDK version in no more available to sdkman.

For example I have this Dockerfile for a project I started working on some days ago:

FROM sdkman-base-image

ARG JAVA_VERSION=8.0.232.hs-adpt
ARG MAVEN_VERSION=3.6.3

# Create java and maven environment
RUN /bin/bash -l -c "export SDKMAN_DIR=/opt/sdkman;. /opt/sdkman/bin/sdkman-init.sh; sdk install java ${JAVA_VERSION}; sdk install maven ${MAVEN_VERSION};"

This Docker image, today, does not build cause 8.0.232.hs-adpt is not available. Today only 8.0.242.hs-adpt of AdoptOpenJDK Host Spot Java 8 image is available for installation via sdkman.

I think that you must be able to install any old version previously available for installation (reproducibility).

PD: It should also be great to specify that you want to install the last bugfix (or minor) version of an specific distribution. For example, sdk install java 8.0.X.hs-adpt or something like that, that "automatically" resolves to 8.0.232.hs-adpt or 8.0.242.hs-adpt whichever is currently the last one available to sdkman.

[rubensa]

Could be related to: sdkman/sdkman-candidates#6

[marc0der]

@rubensa Unfortunately we can't store all historic versions of Java JDKs due to the sheer volume of versions being released. Not only do we have frequent releases, but also many vendors releasing the same version.

Add to that the fact that sdkman is a developer tool first. For the sake of user experience I prefer not flooding the user with outdated versions when listing Java versions (we don't have this issue with other candidates, which all retain exhaustive history) . The best way to contain this for now is by removing the outdated versions for Java.

[marc0der]

Here's a thought. What we could do is add a new visibility flag in the database, so that when we run a database migration we don't actually delete from the db but simply mark it as visible=false. Then when rendering the java list view, we simply ignore historic versions. wdyt?

Of course, I would probably need your help to implement this due to my current limited availability.

[rubensa]

@marc0der The binaries are kept by sdkman infrastructure or are downloaded from third party source infrastructure?

• If sdkman then I understand.

• If thrid party then, I think, that you could keep the full list of historically available options but only show them if, for example, a --all flag is provided on listing (sdk list --all java). In other case, only list "latest" versions (but older versions should be available on request for installation).

[marc0der]

Yep, that was kinda what I was thinking. Please see my previous comment. Also, we only hold the location of where the binaries live.

[rubensa]

Yep, that was kinda what I was thinking. Please see my previous comment.

Sorry, was writing my answer and didn't see yours.

I'll try to help with that (but I'm busy too and had not time to look at the code of this project yet)

[rubensa]

Ouch!!
I don't know Scala language...

Btw I think the needed steps to implement this functionality would be:

• Add current field to database
• Set current value to true for all existing data
• Update cli to not show current=false elements on listing
• Add flag --all to cli to show all elements on listing (despite current value)
• Change database migration process to set current=false for old versions and current=true for new ones.
• Update database with historically available versions (optional)

NOTE: I think current has more functional meaning than visible

[marc0der]

No, current means something completely different in this context and is already a part of our domain language. I prefer visible, as it describes exactly what it is. Anyway, these are just implementation details.

We should also stick to the way that the CLI currently works for consistency so --all isn't going to fly. I prefer to stick to the same command based syntax as we currently us.

[JSamir]

I just stumbled upon this issue after failing to install older versions. I think this is a very important and essential feature for anyone working in the enterprise world, where it is very often the case that we need some older Java version for whatever reason.

Are there any updates? For now i'll probably need to install the older versions manually...

[pere5]

I disagree with "For the sake of user experience I prefer not flooding the user with outdated versions when listing Java versions". Precisely because as you say: "Add to that the fact that sdkman is a developer tool first."
We (developers) will not be confused by a list of versions, I promise. I also think this is an very important and essential feature since specific older versions are very hard to find.

[pveentjer]

No support for older versions is for the primary reason for me not to use this product. I need to be able to switch between different versions to check if a bug has been resolved, or what the performance implications are.

[helpermethod]

@marc0der I would like to tackle this one.