The .mtj metadata file has the version of MTJ used to create that project.
<?xml version="1.0" encoding="UTF-8"?> <mtjMetadata jad="LibSupport.jad" version="0.9.0.qualifier"> <device group="Sun Java(TM) Wireless Toolkit 2.5.2 for CLDC" name="MediaControlSkin"/> <signing signProject="false"/> </mtjMetadata> |
We can use this info to automatically run a migration job.
Diego
Automatically migrating forward is a better idea I think. If we establish a policy in the code that we propagate old versions forward automatically (from X versions back) and ignore with warnings unrecognized fields to handle fall back situations, we should be able to maintain good forward and backward compatibility. Do we have a major/minor version number in the project file we can use to trigger conversions?
Eric Hildum
Senior Product Manager, Mobile Developer Tools & SDK
Software Platforms and Delivery
Ecosystem and Market Development
Motorola
Direct: +1-408-541-6809
Mobile: +1-510-305-0801
809 11th Avenue
Sunnyvale, CA 94089
USA
hi gang,
thanks for the detailed requirements... they look great!
below are some comments
FR001 - Configuration data format & persistence:
if the user already has a MTJ project created with 0.9 what will happen when he opens it with 0.9.1? you mention that the the .mtj file format will be changed.
probably it would be important that the code checks if the project is in the 0.9 format and automatically convert it to the new format (then we would keep workspace compatibility). other options is to have the configurations on another file and keep the .mtj file as it is to have a backword compatibility. not sure if it better. the last option is to just break the workspace compatibility, but i'm not sure if it is a good ideia to do that.
the change on the format also means that a 0.9.1 project will not be opened with MTJ 0.9 isn't it?
Multi-Config: FR003 - manage configurations
do you have some suggestion on the UI workflow for that? besides that, how is the user going to set the current active configuration?
Multi-Config: FR007 - Preprocess symbols content-assist
are we also going to do some kind of validation based on the symbol type? for instance mark the core with "error" if teh develoeprs enter something like //#if screenwidth > "gustavo". not sure if this is necessary (or even possible), but might be good for the user
:)
gep