Chris Hostetter I recall you had suggestions as to how we go about releasing the new UI, but I haven't been able to track them down. ...
My suggestion, along the lines of what we did with the previous UI
1) ensure that the new UI is fully functional in 5x using an alt path
(believe this is already true?)
2) add an "Upgrading" note to CHANGES.txt for 5.2 directing people to
the new "experimental" UI and the URL to access it, note that it
will likely become the default in 5.3 and users are encouraged to try it
out and file bugs if they notice any problems.
3) update trunk so that it is the default UI, and make the old UI
available at some alternate path (eg "/solr/old_ui"). Add an Upgrading
note pointing out that the URLs may be slightly different, and how to
access the old UI if they have problems
- backport trunk changes (#3) to 5x for 5.3 (or later if problems/delays
We might want to tweak those URLs slightly to be a little less confusing
... ie "old.html" and "new.html" (at least until after 5.3) ... i mean, i
just the paragraph you rwote above, but w/o looking at it i've already
forgoten if "index.html" is hte new one or hte old one.
So imagine if a 5.2 user has in their browser...
...and is trying to remember if this is the new one (that they should get
use to / help test) or the fuly qualified name of the old one that is
Likewise imagine if a 5.42 user sees the same URL, and reads a note that
the "old UI" is going to be removed in 6.0 and is trying to figure out if
that affects him.
A few followup comments...
a) that "step 3" above (changing hte defualt on trunk first) is really important ... you want that change to sit on trunk for a good while, so that devs working on trunk and manually testing things are using the new UI anytime they run stuff on trunk, and helping to find problems – even if no users "try" the new UI in the released versions of Solr
b) not sure why i didn't mention it before, but adding a generic header to all of the "old" UI pages warning people that they are using the old UI and here is a link to the new UI is something that should definitely be added once the default is changed (it could be added even before the default is changed with ome wording tweaks: "Please try the new UI.." vs "You are looking at the old deprecated UI, please switch to....") to help reduce the # of bug reports / feature requests we get about the old UI and to reduce user frustration (ie; they see in some future release notes that there is a new collection admin screen, but they can't find it when they load "the admin UI" bookmark they have.)
Having something like "admin#" or "admin/#/" (whatever makes sense for the code) in the URL would likely eliminate that confusion for most people. Even "index.html" in the URL (which the new UI has now) would be helpful, but using the word "admin" in some way would be better.
In the long term, I don't know if this is will actually help things or decrease novice user confusion (the URLs, when loaded in a browser, is already clearly a UI, will making the UI urls longer really help people notice "oh hey, maybe this UI based URL isn't a URL that programtic client code should talk to" ?) but if this approach is taken it should be very carefully considered in terms of how it impacts "reserved words" for things like collection names.
It's annoying enough if we (in the short term) have reserved paths like "/old.ui.html" but if you try to use "/admin" as a prefix to indicate that it's for the UI, you'll probably break things like /admin/cores and /admin/collections – let alone the long term impacts of saying something like "You can't have a collection named 'ui' because of the '/ui'." etc...