How do upgrades to Calatrava framework for projects work?

25 views

Skip to first unread message

priy...@gmail.com

unread,

May 18, 2013, 2:20:26 AM5/18/13

to calatrav...@googlegroups.com

Hi Giles,

I have created couple of small apps (mostly short lived for POC/demo purposes) with Calatrava. In such apps using the latest available version of Calatrava seemed reasonable without having to worry about the future upgrades.

However, going ahead we are trying to use Calatrava in a enterprise kind of an environment. One of the things that I have been thinking about is that right now, "calatrava create <app>" is used to create the bootstrap structure of the project. That remains the base structure for a foreseeable time. The process to move to the next version of Calatrava is very manual and requires the internal understanding of directory structure and such.

Have you given any thought about how the framework itself can be upgraded in existing project? Some of the core things are better off in iOS since POD dependency management is used there and it probably has the ability to pull latest dependency to bring in the benefits?

Also this question spawned from a patch that I am trying to work upon and I am thinking of how to retain the backward compatibility or anticipate the upgrade process.

Currently we would like to use one of the javascript library for some processing in our controllers. Since it's mostly data manipulation, it can run comfortably in js runtimes on both iOs and Android. However, currently there is no good place to place a library or specify a library to indicate that it should be loaded with web runtime. To be able to do so, a logical choice seems that manifest.yml structure should evolve to say

features:
- feature 1
- feature 2
libraries:
- library 1
- library 2

Or something similar. However this means, that if older applications upgrade the framework, expectation of the manifest.yml structure would have changed. So here are couple of questions:

- Have you had to do such structure migrations that would break the older versions. If yes, did you follow a pattern which I can use just to be consistent?
- Do you anticipate/plan for projects to be able to upgrade calatrava framework "automagically" or it will remain a manual and debugging based process for foreseeable time?
- Does the approach about to group configuration of files to be loaded for environments in manifest.yml seems appropriate? I am trying to ensure that configs live in one place so that user doesn't have to hunt down multiple libraries. (Not all libraries can be loaded in web runtime currently, since anything that needs a handle of "window" object blows up in RhinoContainer in android)?

Would love yo hear your views. Meanwhile I'll submit a patch for this. Let me know your thoughts and I can probably tweak it to accomodate the recommendations.