The latest/ directory in git repository

[praiskup]

Comply with sclorg/container-common-scripts#4

[praiskup]

Preparing this PR eats some energy, so if we agree that something like this is worth it (and there's some reviewer and committer), I'll rebase and re-propose.

[pkubatrh]

As stated in sclorg/container-common-scripts#4 this gets a +1 from me.
The only issue I have is that with 9.5/ being a symlink to latest we effectively lose all existing links (and the ability to link) to the 9.5/ code on github.

[praiskup]

The only issue I have is that with 9.5/ being a symlink to latest we effectively lose all existing links (and the ability to link) to the 9.5/ code on github.

The question is whether it is correct to reference file in "9.5" directory.. something like this was also mentioned in 0860eb4

Having "single source of truth" could resolve this once and forever..

[omron93]

+1 from me too.

One question, where to write "rule" like this? (other sclorg/ images should follow this PR and have latest/ version too)

[pkubatrh]

The question is whether it is correct to reference file in "9.5" directory.. something like this was also mentioned in 0860eb4

I agree with the question but from the comment on the commit you linked it seems some people actually link to the repository this way.
I mean this is by no means a blocker for me, it's just something I wanted to throw into the discussion. If we want we could also mitigate this by waiting until the next version of the image (9.6) and make a symlink out of that one.

[praiskup]

@torsava, @hhorak FYI.

Btw., if (at the time of branching) we moved 9.5 to 9.6, and created the new 9.5 directory (what @torsava proposed I believe) we would loose the history because git thinks that 9.5 stayed "unchanged" and 9.6 is new. So we would have to have two commits for each "branching" time ... (1. commit does the movement, and the 2. commit C&P). So in the end, the "latest" + symlink alternative sounds like we can more easily "enforce" such guideline.

[praiskup]

I mean this is by no means a blocker for me, it's just something I wanted to throw into the discussion. If we want we could also mitigate this by waiting until the next version of the image (9.6) and make a symlink out of that one.

I neither feel we are blocked here, and waiting is IMO not that important (if there were such links to 9.5, those would be soon fixed once we move latest to 9.6 version).

[torsava]

Btw., if (at the time of branching) we moved 9.5 to 9.6, and created the new 9.5 directory (what @torsava proposed I believe) we would loose the history because git thinks that 9.5 stayed "unchanged" and 9.6 is new. So we would have to have two commits for each "branching" time ... (1. commit does the movement, and the 2. commit C&P). So in the end, the "latest" + symlink alternative sounds like we can more easily "enforce" such guideline.

Indeed you would need 2 commits. I like the moving alternative because I feel it makes the repo cleaner, but I agree it would be impossible to enforce and thus using the latest approach will likely be more sustainable.

[hhorak]

I like this approach as well (sorry for delay).

[praiskup]

I rebased the PR; the first commit is prerequisite from PR #180.

[pkubatrh]

help.1 file present in latest, probably a leftover from the deprecated 9.2

[praiskup]

Good catch, thanks! Should be fixed.

[pkubatrh]

lgtm. Lets merge and try out this approach.