This error: Eclipse downloads - file unavailable The selected file is invalid, or it is no longer available for download.
What is the correct behavior?
For pages like https://www.eclipse.org/downloads/packages/release/2022-06 to have only R packages in them (perhaps auto-redirect to the /r subdir). Note that older releases (<= Oxygen) have multiple valid subpages, e.g. R, 1A, 2, etc.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
I am a bit confused here on why some links work and some others don't. I was under the impression that we had the responsibility of making all these releases available for download. Is that incorrect?
Is there an archiving process that's happening that I am not aware of?
I do agree with @jograham that we should probably remove them if it's no longer possible to download them but before we take action, I would like to better understand why some of these links no longer work to make sure we are doing the right thing.
The broken links are to Milestones and Release Candidates only which are discarded once the Release is made.
Hi @cguindon - the general retention policy (implemented by "Remove the old M and RC builds" step in the EPP release process) is to only keep releases, as a result milestones and release candidates are discarded soon after the final release is made (normally by M1 of the next release).
Note part of the confusion in this area may arise because of the overloading of the word "release". It ends up having two meanings for the Eclipse IDE. Every Milestone and Release Candidate gets "released" aka "published" on the Friday according the the release schedule. A milestone ends up in the "Releases" location on eclipse.org (e.g. https://www.eclipse.org/downloads/packages/release/2022-06/m3). But only the R-build* is actually a release in the EDP sense. I try not to use the word "release" when talking about milestones, but I have found it difficult.
Hopefully that fully clarifies the situation.
* Note that older releases (<= Oxygen) have multiple releases, e.g. R, 1A, 2, etc.
* Note that older releases (<= Oxygen) have multiple releases, e.g. R, 1A, 2, etc.
This is an important detail. For older releases (<= Oxygen), can you provide a list of all the releases that we need to keep to ensure that we do this right?
Since there is more than 1 release for these older ones, could you also let me know which one I should use to redirect traffic from milestones and release candidates?
For example, I would assume that we would want to keep R, SR1, and SR2 for Eclipse Indigo. I would also assume that we would want to redirect all the SR*, RC* AND M* releases to SR2? Did I get this right?
* Note that older releases (<= Oxygen) have multiple releases, e.g. R, 1A, 2, etc.
This is an important detail. For older releases (<= Oxygen), can you provide a list of all the releases that we need to keep to ensure that we do this right?
Since there is more than 1 release for these older ones, could you also let me know which one I should use to redirect traffic from milestones and release candidates?
I think you should redirect to the release's page.
For example, I would assume that we would want to keep R, SR1, and SR2 for Eclipse Indigo. I would also assume that we would want to redirect all the SR*, RC* AND M* releases to SR2? Did I get this right?
I don't know how much value there is at all in these old pages. The important part, the downloads themselves are retained on https://archive.eclipse.org/technology/epp/downloads/release/ . Other companies don't keep the flashy pages around for releases that are so old.
There is a minor error on all the non /r pages, they are incorrectly listed as a Developer Build:
I don't know how much value there is at all in these old pages.
I think it may be best to just get rid of all pages before the numbered releases. Let me check around and get back to you. It feels like spending time fixing these old pages is wasted when they probably should just be deleted.
For the other pages (>= 2018-09) the updates as discussed above are desired. I think by doing this version range means no special cases, so hopefully that simplifies things.
That looks good @epoirier, it is good that the old releases are not listed.
for 2023-03 until its release?
We're still working on 2022-12. Right now we have no developer releases available, first one is scheduled for next Thursday/Friday.
I am assuming you have an old copy of the database since the page is missing all the 2022 releases..?
Also the "Eclipse Installer 2021-03 R [...]" link on the right doesn't match even the latest in your list on the left. The current live webpage looks right, so I assume that this is also an artifact of dev environment?
@cguindon My understanding is that M and RC releases are being displayed on the release page itself.
Example: /release/2022-09
But with my changes, I'm fetching all releases given that they have been created after July 23, 2018.
Yes my database is pretty old, didn't think I needed a fresh copy for what I needed to do here.
@jograham My screenshot was simply to give an idea of what items I removed from the list. I can definitly update my local database to show the exact list that we will see on production once my changes are live.
Thanks @epoirier - looks good to me then. Let me know when it is live and I will have a look. I can't see the MR you linked to because I assume I don't have such permissions.
When an R release is available, the links are redirecting to that page. If not, a new page opens to let you choose the release version (just like it was before).
There is one small issue I noticed. When a redirect from an M or RC build sends to the R page, the Please note that this is a developer build which might contain issues. is still shown.
Also, on the redirected page the Search in the upper-right is present, in direct it is not present:
Finally, the link to directly download the installer on the right seems correct when redirected (left side) but incorrect when directly visiting (right side). I am on linux, and the links on the left are for linux, on the right are for windows.
Here is the diff of a prettified version of the HTML with redirect and without
Because of the last item, the download link being incorrect, I am reopening this issue. I don't know if this is a regression caused by this change or something I simply never noticed before. Let me know if you prefer I submit this is a new issue.
I created a merge request to fix the warning message being printed on the wrong page.
From what I can see the search only appears on the developer build page. I'll have to investigate.
I can't reproduce this locally but I do see the issue on production. The reason why you're seeing Windows links is because Windows is the default in our code. I'll need to investigate this further as well.
Note that when I login as an admin on the packaging website, I do see the proper links (Linux for me). But when I'm viewing the site as an anonymous user, I see a Windows link in the installer block.
@cguindon I think it was reopened to look into the sidebar and the search but I believe we took care of those issues when updating the caching in the sidebar and we merged a commit to update the search form in the menu.
I think I simply forgot to close this issue when we did this 2 weeks ago.
@jograham can you confirm all is good with the changes that we made?
There are still some pages where the search doesn't appear (for me), e.g. https://www.eclipse.org/downloads/packages/release/2022-12/m2 so there is still some inconsistency in that regard. This is minor and marginal, please feel free to split it out to a new issue as the main purpose of this issue is fully resolved.