| Previous · Next | |
| User | Message |
|
apeiron
|
Date: 5/24/2008 1:25 pm · Subject: Three feature requests for Lift, once we get the tuits · Rating: 0
I've been doing a lot of incremental development on a couple of customer-requested features. They're running a stable version of WebGUI, so these features take the form of incremental patches. There was recently some confusion about whether a previous patch had been installed when I delivered a newer patch. I would like to propose the following features for Lift, once we get the tuits: 1. A journal of things previous patches have changed. This will exist at both the site (i.e., MySQL database for each specific site) and the code level. It will need to exist at both levels because code changes affect all sites, whereas DB changes only affect the database to which the change was applied. This will allow one to ascertain where a certain site is in the path of incremental patches and what needs to be applied to bring it up-to-date. This feature works together with feature 2. 2. Prerequisites for patches. For example, if one wants to install a patch which modifies feature XYZ but they didn't apply the patch that added feature XYZ, they shouldn't be able to do so. Granted, one can attempt to fix this with documentation and communication. However, I prefer mandatory, rather than discretionary, permissions. The way this will work is that a patch (or part of a patch, see feature 3) will refuse to apply before the prerequisite is installed. The failure message should detail which feature is missing and any other information needed to acquire and install the feature. Lift may also present the option of downloading and installing the feature, if possible. The above two features, combined and applied, lead to 3. Fine-grained patch actions. What this means is that there should be a separation that exists between each individual thing that a patch does. Database updates should be separate from code updates, database updates for site ABC should be separate from database updates for site DEF, etc. This way, the journal and the prerequisites may be more fine- grained. But that's not all. Fine-grained patch actions allow the user to apply part of a patch without applying another part. For example, if I provide a code + DB patch, the user should be able to apply the DB patch to the specific sites they want, and apply the code patch to the code. I recognize that this is probably a power-user feature, but I firmly believe in giving the user the power they request if they ask for it in an explicit, unequivocal fashion. Thoughts? This would make my life much easier. Chris Nehren // Plain Black p 1.703.286.2525 x 811 m 1.267.573.1000 f 1.312.264.5382 |
| Back to Top |
Rate [ | ]
|
