[jbosstools-issues] [JBoss JIRA] (JBIDE-20993) http://download.jboss.org/jbosstools/ contains wrong versions

[ https://issues.jboss.org/browse/JBIDE-20993?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-20993 at 10/20/15 1:45 PM: -------------------------------------------------------------- I put these in place to mirror what's on https://devstudio.redhat.com -- * https://devstudio.redhat.com/9.0 == https://devstudio.redhat.com/mars * https://devstudio.redhat.com/10.0 == https://devstudio.redhat.com/neon The reason for this is to simplify some of the release engineering / publishing / auditing scripts, so that we can key in on a common "mars" or "neon" path segment regardless of whether we're working with JBT or JBDS. But then I thought, if there's a symlink from 9.0 -> mars on the ds.jb.com server, surely we should have the opposite symlink on the dl.jb.o server, mars -> 9.0. This has been in place since May 21, 2015. I added the equivalent 10.0 / neon links on Sept 18, 2015. I don't recall if there was an announcement about this since I considered it simply a releng thing not worthy of announcement. And "under the covers" change, if you will. While I understand your fear/confusion/rage, I still believe that having a logical mapping on the servers between the JBDS versioning and the JBT versioning is a good thing. -- Would you be happy if instead of a /10.0/ folder for JBDS, we simply used a /neon/ folder? I would +1 that plan, if you really don't like seeing "10.0" on the dl.jb.o server. At least that way the folder structure would be identical for both JBT and JBDS, as they'd both target a /neon/ folder. Thus we would publish to URLs like these: {quote} https://devstudio.redhat.com/neon/snapshots/builds/ https://devstudio.redhat.com/neon/snapshots/updates/ https://devstudio.redhat.com/neon/staging/builds/ https://devstudio.redhat.com/neon/staging/updates/ and http://download.jboss.org/jbosstools/neon/snapshots/builds/ http://download.jboss.org/jbosstools/neon/snapshots/updates/ http://download.jboss.org/jbosstools/neon/staging/builds/ http://download.jboss.org/jbosstools/neon/staging/updates/ {quote} instead of {quote} https://devstudio.redhat.com/10.0/snapshots/builds/ https://devstudio.redhat.com/10.0/snapshots/updates/ https://devstudio.redhat.com/10.0/staging/builds/ https://devstudio.redhat.com/10.0/staging/updates/ and http://download.jboss.org/jbosstools/neon/snapshots/builds/ http://download.jboss.org/jbosstools/neon/snapshots/updates/ http://download.jboss.org/jbosstools/neon/staging/builds/ http://download.jboss.org/jbosstools/neon/staging/updates/ {quote} (Of course there would also be similar URLs with /development/ and /stable/ in future.) was (Author: nickboldt): I put these in place to mirror what's on https://devstudio.redhat.com -- * https://devstudio.redhat.com/9.0 == https://devstudio.redhat.com/mars * https://devstudio.redhat.com/10.0 == https://devstudio.redhat.com/neon The reason for this is to simplify some of the release engineering / publishing / auditing scripts, so that we can key in on a common "mars" or "neon" path segment regardless of whether we're working with JBT or JBDS. But then I thought, if there's a symlink from 9.0 -> mars on the ds.jb.com server, surely we should have the opposite symlink on the dl.jb.o server, mars -> 9.0. This has been in place since May 21, 2015. I added the equivalent 10.0 / neon links on Sept 18, 2015. I don't recall if there was an announcement about this since I considered it simply a releng thing not worthy of announcement. And "under the covers" change, if you will. While I understand your fear/confusion/rage, I still believe that having a logical mapping on the servers between the JBDS versioning and the JBT versioning is a good thing. -- Would you be happy if instead of a /10.0 folder we simply used a /neon/ folder? I would +1 that plan, if you really don't like seeing "10.0" on the dl.jb.o server. At least that way the folder structure would be identical for both JBT and JBDS, as they'd both target a /neon/ folder. -- This message was sent by Atlassian JIRA (v6.4.11#64026)