| I’ve added my comments inline below.
Hi, Peter,
Thanks for taking this updated setup model for a spin. See some replies in-line, below.
On 3 October, 2016 at 04:15:41, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote: Hi,
I tested the updated developer setup with the new variable. One implication of this was that I had to switch to advanced mode when installing. Previously I always made the installation of the tester setup, using the simple mode.
I’m so used to Advanced Mode that I’ve pretty much forgotten that the Simple Mode even exists. We can, if we choose to ship a shrink-wrapped installer for Papyrus-RT testers, customize it to show the Advanced Mode by default on the first launch. But, considering that this is for testers, which are already an advanced user community (having deep knowledge of Papyrus-RT development), I see no problem in requiring the advanced mode to get an alternative Papyrus build into the configuration.
<cr>I agree. This setup is not for modeling users, they are for testers and fearless advanced modelers who should have more skills with regards to the Eclipse environment. Advanced mode should be fine for these users.
Note that the current goal is for modeling users, especially beginners, to download an RCP in the 1.0 timeframe.
</cr>
Apart from this I also realized that I now will have a bit hard time knowing/remembering which choice I have made for this single tester setup. And what about if I want to have both a nightly setup and a release setup installed at the same time? Sure I can manually ensure installations into separate folders, instead of just picking the default location. But it requires some more work, and you manually have to create icons on your desktop so you loose some of the convenience that you get from using the Eclipse Installer.
The selection of the Papyrus build kind is stored by Oomph on a per-installation basis (the installations of Papyrus-RT that it provisions). So, you can create one Papyrus-RT instance on the Papyrus nightlies and another instance on the Papyrus releases. Then, whenever you re-run the Oomph setup from within each of these Papyrus-RT workbenches, they will each remember their separate setting of this variable and will get the correct updates. Also, you can at any time hit the Back button from the default page of the “Run Setup” wizard to see the variables that are in effect (you may have to hit the “Show all variables” check-box).
This is typically how I’ve been working.
Maybe it would be better to actually have different "product versions" defined (compare with the end-user setup where you can select 0.7.0, 0.7.1, 0.7.2 and current). Then you solve both the issue of making the selection available in simple mode, as well as making it possible to have both a nightly and a release tester version installed at the same time (and automatically getting icons on the desktop named according to the different product versions).
Perhaps, but they aren’t different versions of Papyrus-RT. They are the same version of Papyrus-RT (0.8, actually even the same build of Papyrus-RT) installed on top of different builds of the same version of Papyrus (Neon.x).
The tester setup is really only for a single version/milestone: the one currently under development. Doing work on previous versions/milestones may need to be considered, but, I would contend, only after we get to a 1.0 release. As such, is there really a need to keep track of various builds/versions/milestones? I would not think so - and if there is a case where this is a concern for the tester, they should have the skills to keep a workbench installation without updating it.
|
