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
