Mark Posted June 3, 2016 Share Posted June 3, 2016 We have made some changes in IPS Community Suite 4.1.13 to how versions of applications or plugins are managed. What has changed? Currently, when you start working on a new version of your application, you go to the "Versions" tab and add the version number and ID for the version you're about to begin developing. When you make any database changes, the system automatically adds the necessary queries to the upg_xxx folder for that version. With these changes, you will no longer create the version at the start of the development process. There will be a special "upg_working" folder which stores the changes as you make them, and when you build an application or plugin to release it (either by building or downloading in the AdminCP on your development install) you will be prompted for the version number and ID to use, and the "upg_working" folder will be renamed. You can still "rebuild" without specifying a new version if you want. Why are we making this change? Sometimes we'll be working on a new version and something comes up (like a security issue) which means we need to release a version we weren't planning. Or sometimes we'll start working on a feature and it doesn't end up going in the version we were planning. Currently both these situations mean we have to go and manually adjust the contents of the upg_xxx folders, which is time consuming. With this change, the system doesn't assign an ID to a version until you're actually releasing, which makes such situations much easier to manage. What do I need to do? When you upgrade your development install to 4.1.13, if you have a version you've added in the developer center but not yet released: Remove it's entry from the versions.json file in your data folder. Rename the upg_xxx folder in your setup folder to "upg_working". Note you will also have to rename the class name if it contains an upgrade.php file. After that, simply do not create new versions when you start working on them, and follow the instructions when building your application or plugin. Link to comment Share on other sites More sharing options...
Aiwa Posted June 3, 2016 Share Posted June 3, 2016 This only impacts the database changes, though. What about file-system changes? I've added an ActiveRecord to manage the new table in the next version, but I need to release a bug fix version before that feature is complete. Will the ActiveRecord and any functions I've written that call it still be included in the build? Or do I have to revert the file system, rebuild the app, then restore the change for my feature release? Link to comment Share on other sites More sharing options...
CodingJungle Posted June 3, 2016 Share Posted June 3, 2016 what about hooks as well? Its a nice feature, just needs some tweaks to make it a Great Feature :). Link to comment Share on other sites More sharing options...
Mark Posted June 4, 2016 Author Share Posted June 4, 2016 On 3 June 2016 at 5:43 PM, Aiwa said: This only impacts the database changes, though. What about file-system changes? I've added an ActiveRecord to manage the new table in the next version, but I need to release a bug fix version before that feature is complete. Will the ActiveRecord and any functions I've written that call it still be included in the build? Or do I have to revert the file system, rebuild the app, then restore the change for my feature release? I'm not totally sure understand the question, but "build" still does the same thing it's always done (takes the /dev files and puts them in xml files) it just now adds a version to versions.json and renames upg_working first whereas before it expected you to have the version already in it and a proper upg_xxx folder already. On 3 June 2016 at 9:10 PM, CodingJungle said: what about hooks as well? Its a nice feature, just needs some tweaks to make it a Great Feature :). Plugins follow the same process but are less impacted because they have less automatic version managing stuff. Link to comment Share on other sites More sharing options...
Aiwa Posted June 5, 2016 Share Posted June 5, 2016 2 hours ago, Mark said: I'm not totally sure understand the question, but "build" still does the same thing it's always done (takes the /dev files and puts them in xml files) it just now adds a version to versions.json and renames upg_working first whereas before it expected you to have the version already in it and a proper upg_xxx folder already. Plugins follow the same process but are less impacted because they have less automatic version managing stuff. That's what I figured. The files and templates in the app folder would need to be restored to a previous version if you have to release an unexpected bug fix release. This only appears to help with schema changes. Link to comment Share on other sites More sharing options...
CodingJungle Posted June 5, 2016 Share Posted June 5, 2016 I actually meant the hooks in the applications, not plugins Link to comment Share on other sites More sharing options...
Mark Posted June 5, 2016 Author Share Posted June 5, 2016 10 hours ago, Aiwa said: That's what I figured. The files and templates in the app folder would need to be restored to a previous version if you have to release an unexpected bug fix release. This only appears to help with schema changes. Oh right, yes - if you wanted to go back to a previous version of a file you'd need to do that manually. We use different git branches. 8 hours ago, CodingJungle said: I actually meant the hooks in the applications, not plugins I'm not sure what you mean. Link to comment Share on other sites More sharing options...
steve00 Posted June 5, 2016 Share Posted June 5, 2016 Does this affect themes ... either using Designers Mode or using Manual HTML/CSS option (especially if creating theme and have to upgrade IPS to new version .... will this affect any themes not finished) ? Link to comment Share on other sites More sharing options...
CodingJungle Posted June 5, 2016 Share Posted June 5, 2016 7 hours ago, Mark said: Oh right, yes - if you wanted to go back to a previous version of a file you'd need to do that manually. We use different git branches. I'm not sure what you mean. well database changes are only small part of development. there are often times i never touch the database, but if I add a hook and need to fix a problem before i'm done with the hook, the hook will be included in the "unexpected" release. was curious if they will also be handled like db changes with this system. Link to comment Share on other sites More sharing options...
Mark Posted June 6, 2016 Author Share Posted June 6, 2016 13 hours ago, CodingJungle said: well database changes are only small part of development. there are often times i never touch the database, but if I add a hook and need to fix a problem before i'm done with the hook, the hook will be included in the "unexpected" release. was curious if they will also be handled like db changes with this system. No, hooks are simply a file change (hooks.json). Always use appropriate source control (like a different git branch for a new feature) and the change described here will make managing that less painful than before. Link to comment Share on other sites More sharing options...
CodingJungle Posted June 6, 2016 Share Posted June 6, 2016 was just curious to the extent of what changes it kept track of in this special folder. I already use GIT for version control, there are times the framework makes it difficult, we'll see how this helps out. Link to comment Share on other sites More sharing options...
Midnight Modding Posted June 10, 2016 Share Posted June 10, 2016 Good idea. I have done that before, planned on something being in version x.y.z and then needed to release something before finishing it. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.