You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am tasked, here at Global Phasing, with integrating our workflow engine in MXCuBE. As you might imagine, we want to be able to start testing things as soon as we can (in-house first), and we want to be able to work with different synchrotrons, that run different user interfaces and versions. I need to make a couple of hardware objects, integrate things in the MXCuBE queue and user interface etc. And being new to both the project and to git I am not that sure what it the best way to go about it.
Ideally one would want a starting point that could be used with both the web and Qt4/5 interface with minimal modifications (we are hoping to bypass the Qt3 version and go directly to web). But if there is a branch of HardwareObjects that can slot in directly with both the web interface and the Qt4 interface, I cannot figure out how to do it. And I cannot easily figure out what things are different between e.g. master and 2.2, and what things are or will be kept in sync.
The best I came up with was to make my branches off HardwareObjects 2.2 and HardwareRepository master, keep them in sync as I work, and do the first in-house tests with MXCuBE3 (master). Hopefully it should be possible to merge changes in HardwareObjects 2.2 into a branch off HO master without too much trouble, and so get a branch that could be tested with the Qt4 interface (mxcube2 master). And it ought to be easier to start in 2.2 and upgrade to master, than to start using all the things available in master and then 'downgrading' to HO 2.2 for the web interface.
But I could easily have got this one wrong. Can anyone suggests a better way, in detail or overall, to start developing a feature that is not targeted at one specific UI and version from the start?
Rasmus
The text was updated successfully, but these errors were encountered:
Branches 2.1, 2.2 and master were synchronized at the end of the last year and in general there are no fundamental changes. With fundamental changes I mean changes in the queue. I would suggest to use master branch because it is our development branch and branches 2.x should be stable release branches. As you know we are progressing towards a new release 2.3 which will be based on master with all changes from 2.1 and 2.2. (mxcube/HardwareObjects#82)
Hi,
I am tasked, here at Global Phasing, with integrating our workflow engine in MXCuBE. As you might imagine, we want to be able to start testing things as soon as we can (in-house first), and we want to be able to work with different synchrotrons, that run different user interfaces and versions. I need to make a couple of hardware objects, integrate things in the MXCuBE queue and user interface etc. And being new to both the project and to git I am not that sure what it the best way to go about it.
Ideally one would want a starting point that could be used with both the web and Qt4/5 interface with minimal modifications (we are hoping to bypass the Qt3 version and go directly to web). But if there is a branch of HardwareObjects that can slot in directly with both the web interface and the Qt4 interface, I cannot figure out how to do it. And I cannot easily figure out what things are different between e.g. master and 2.2, and what things are or will be kept in sync.
The best I came up with was to make my branches off HardwareObjects 2.2 and HardwareRepository master, keep them in sync as I work, and do the first in-house tests with MXCuBE3 (master). Hopefully it should be possible to merge changes in HardwareObjects 2.2 into a branch off HO master without too much trouble, and so get a branch that could be tested with the Qt4 interface (mxcube2 master). And it ought to be easier to start in 2.2 and upgrade to master, than to start using all the things available in master and then 'downgrading' to HO 2.2 for the web interface.
But I could easily have got this one wrong. Can anyone suggests a better way, in detail or overall, to start developing a feature that is not targeted at one specific UI and version from the start?
Rasmus
The text was updated successfully, but these errors were encountered: