[mapguide-internals] RE: API Operation Version Confusion

Tom Fukushima tom.fukushima at autodesk.com
Mon Aug 17 17:17:33 EDT 2009


The only thing I could see as a benefit to the 1.0.0 approach is that you always know there is a 1.0.0 version of the particular API you are using.  This could help you quickly rule out that filling in the wrong version number is the thing that is causing the request to fail (putting in an unknown version number like 1.0.0 *will* cause the request to fail)---other than that I don't know of any reason to use it; and I personally *don't* believe that this is a strong reason to use it.

What value does syncing with the web API version add? I can see that if you write a MapGuide application you may be able to figure out which version of the web tier is required if you look for "VERSION=" strings.  I'm not sure how useful this is or how accurate it would be though.  Anything else?

Is it a downside that we cannot extend APIs without revving the version? I don't think that this is a negative; as Trevor says, we should not be lazy and always rev the version for any change.

We would need to see what the use of this is before we decide how much backwards incompatibility we introduce.  Give the above reasons I don't think that they are strong enough to make us break compatibility.
 
I would like to hear concrete reasons from application developers on which they would prefer.  Ultimately, we want to cater to them.  Choosing one or the other doesn't matter for the core developers.

Tom



-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Monday, August 17, 2009 2:06 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: API Operation Version Confusion

That makes sense to me too.  Using the web api version rather than a function-specific revision adds a lot of value.

I guess my question though is, how do we move to consolidate on this system without causing backwards compatibility issues?  Is it too late to standardise on this system and gain value from it?

Jason

-----Original Message-----
From: Dave Wilson
Sent: Monday, August 17, 2009 1:01 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: API Operation Version Confusion

I'm not sure what the standard for this in open source, but logically the version reflects the version the API was introduced in or updated in. If it hasn't been updated the version wouldn't change. This would act like a label so that you can find all the 1.0.0 APIs, the 1.2.1 APIs (or revisions) and so on. That would seem like useful information to me. If an API doesn't have a 1.0.0 version you know it was introduced later.

-----Original Message-----
From: Bruce Dechant
Sent: Monday, August 17, 2009 1:51 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] API Operation Version Confusion

I would like to discuss the confusion on the API version information.

Currently, all of the APIs have an associated operation "VERSION". This "VERSION" hasn't been clearly defined and after looking at the latest code base we are using it inconsistently throughout the project.

As you can see we have not been following a well defined operation "VERSION" scheme and this is something we need to correct as it is confusing.

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


More information about the mapguide-internals mailing list