Standardize Auto-Update response

[Peter Wagemans]

Jake, Micah and I have been discussing this before.

The problem is that currently, there is no unified way to query the version of a plug-in so it can be used to compare the version of a
plug-in against a previous version of a plug-in.

This is needed if one wants to build a FileMaker template that takes care of downloading the latest and greatest from the FileMaker
server, for all plug-ins currently installed, even when from different vendors.
It can be more or less done using specific code for each plug-in or brand, but it remains a pain to configure this, because it's always
done differently.

The reason the discussion is brought to the group here is obvious. We need more plug-in developers to know about this need, and
recognize and respect some minimal standard.

We are at the point where we agreed on the following ( I think):

- 4 levels
- numeric
- a separate human readable version number
- 2 digits per level maximum
- version returned in the format aabbccdd where every letter represents a digit of the level, so versions can be easily compared.

The proposed syntax was <plug-in>_Version ("AutoUpdate")
We also agreed to keep existing the version function syntax in order not to break existing solutions.
I hope I did not forget to mention other things.

----

We were at the point where Micah proposed a separate <plug-in>_AutoUpdateVersion().

---

To reply to this:

I think it's important that we rally reach a standard, and fomalise some stuff. For the moment, we seem to have obtained a level of
detail enough to create a standard. Let's call the current setup ( as described above ) version 0.
Everytime we vote to decide to change anything, we can up that number.

Micah, ro reply to your suggestion: I think it's clean, but more work to adapt current development. Now, it's just reacting to 1 more
other possible parameter in an existing function, as a new function, it needs its own prototype…etc.
So I'm against it - man do I hate begin negative - but maybe Jake likes the idea, in which case we just gave birth do version 1...:-)

[Jake Traynham]

Hello all,

   Having a separate <plugin>_AutoUpdateVersion function is fine with
me, it's not that big of a deal to add that function in real quick and I
would probably just have it call my other version function anyway.
However, I do have one other slight change to your proposal.  You said
to have the number format be aabbccdd, but I would actually prefer
aa.bbccdd, and not just because that's how I currently do it. :)  It
makes sense in my head to have the major version number be the whole
number part while the minor/update/beta part be the fractional part.
This seems to be how other version number schemes seem to work.

Thanks,
Jake

clarifiks wrote:

>
>
> Jake, Micah and I have been discussing this before.
>
> The problem is that currently, there is no unified way to query the
> version of a plug-in so it can be used to compare the version of a
> plug-in against a previous version of a plug-in.
>
> This is needed if one wants to build a FileMaker template that takes
> care of downloading the latest and greatest from the FileMaker
> server, for all plug-ins currently installed, even when from different
> vendors.
> It can be more or less done using specific code for each plug-in or
> brand, but it remains a pain to configure this, because it's always
> done differently.
>
> The reason the discussion is brought to the group here is obvious. We
> need more plug-in developers to know about this need, and
> recognize and respect some minimal standard.
>
> We are at the point where we agreed on the following ( I think):
>
> - 4 levels
> - numeric
> - a separate human readable version number
> - 2 digits per level maximum
> - version returned in the format aabbccdd where every letter represents
> a digit of the level, so versions can be easily compared.
>
> The proposed syntax was <plug-in>_Version ("AutoUpdate")
> We also agreed to keep existing the version function syntax in order not
> to break existing solutions.
> I hope I did not forget to mention other things.
>
> ----
>
> We were at the point where Micah proposed a separate
> <plug-in>_AutoUpdateVersion().
>
> ---
>
> To reply to this:
>
> I think it's important that we rally reach a standard, and fomalise some
> stuff. For the moment, we seem to have obtained a level of
> detail enough to create a standard. Let's call the current setup ( as
> described above ) version 0.
> Everytime we vote to decide to change anything, we can up that number.
>
> Micah, ro reply to your suggestion: I think it's clean, but more work to
> adapt current development. Now, it's just reacting to 1 more
> other possible parameter in an existing function, as a new function, it
> needs its own prototype…etc.
> So I'm against it - man do I hate begin negative - but maybe Jake likes
> the idea, in which case we just gave birth do version 1...:-)
>
>

--
Jake Traynham
Owner, CNS Plug-ins
http://www.cnsplug-ins.com/


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/fmplug-prog-list/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/fmplug-prog-list/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[hidden email]
    mailto:[hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Micah Woods]

One of my concerns is that some plug-ins already accept parameters for the
version function.

For example, the DoSQL version function has a dataSelector parameter that¹s
defined as a number from 0 to 8.

Would you be changing this function to accept the string ³AutoUpdate²?

Our version function doesn¹t accept any parameters so it¹s easy for us to
add an optional ³option² param. It looks like the Dacons folks have taken
this route (I¹m looking at their manual for ScriptFire). The options they
support are ³Version², ³Product², ³Platform² and ³Copyright².

So, the 2 ideas are:

Version 0:
<plug-in>_Version( {option} )

Version 1:
<plug-in>_AutoUpdateVersion

I¹d be happy with either.

Regards,
Micah


on 8/2/08 6:03 AM, clarifiks at [hidden email] wrote:

>  
>  
>
> Jake, Micah and I have been discussing this before.
>
> The problem is that currently, there is no unified way to query the version of
> a plug-in so it can be used to compare the version of a
> plug-in against a previous version of a plug-in.
>
> This is needed if one wants to build a FileMaker template that takes care of
> downloading the latest and greatest from the FileMaker
> server, for all plug-ins currently installed, even when from different
> vendors.
> It can be more or less done using specific code for each plug-in or brand, but
> it remains a pain to configure this, because it's always
> done differently.
>
> The reason the discussion is brought to the group here is obvious. We need
> more plug-in developers to know about this need, and
> recognize and respect some minimal standard.
>
> We are at the point where we agreed on the following ( I think):
>
> - 4 levels
> - numeric
> - a separate human readable version number
> - 2 digits per level maximum
> - version returned in the format aabbccdd where every letter represents a
> digit of the level, so versions can be easily compared.
>
> The proposed syntax was <plug-in>_Version ("AutoUpdate")
> We also agreed to keep existing the version function syntax in order not to
> break existing solutions.
> I hope I did not forget to mention other things.
>
> ----
>
> We were at the point where Micah proposed a separate
> <plug-in>_AutoUpdateVersion().
>
> ---
>
> To reply to this:
>
> I think it's important that we rally reach a standard, and fomalise some
> stuff. For the moment, we seem to have obtained a level of
> detail enough to create a standard. Let's call the current setup ( as
> described above ) version 0.
> Everytime we vote to decide to change anything, we can up that number.
>
> Micah, ro reply to your suggestion: I think it's clean, but more work to adapt
> current development. Now, it's just reacting to 1 more
> other possible parameter in an existing function, as a new function, it needs
> its own prototype…etc.
> So I'm against it - man do I hate begin negative - but maybe Jake likes the
> idea, in which case we just gave birth do version 1...:-)
>
>  
>    

[Peter Wagemans]

It all makes sense. So we're at version 1 with <plug-
in>_AutoUpdateVersion() without any parameters.

Jake wrote:
> However, I do have one other slight change to your proposal.  You said
> to have the number format be aabbccdd, but I would actually prefer
> aa.bbccdd, and not just because that's how I currently do it. :)  It
> makes sense in my head to have the major version number be the whole
> number part while the minor/update/beta part be the fractional part.
> This seems to be how other version number schemes seem to work.

Jake, have you considered that a big part of the world does not use a  
dot as the decimal separator?
-- peter

On 4-aug-08, at 17:32, Micah Woods wrote:

> One of my concerns is that some plug-ins already accept parameters  
> for the version function.
>
> For example, the DoSQL version function has a dataSelector parameter  
> that’s defined as a number from 0 to 8.
>
> Would you be changing this function to accept the string  
> “AutoUpdate”?
>
> Our version function doesn’t accept any parameters so it’s easy  
> for us to add an optional “option” param. It looks like the  
> Dacons folks have taken this route (I’m looking at their manual for  
> ScriptFire). The options they support are “Version”,  
> “Product”, “Platform” and “Copyright”.
>
> So, the 2 ideas are:
>
> Version 0:
> <plug-in>_Version( {option} )
>
> Version 1:
> <plug-in>_AutoUpdateVersion
>
> I’d be happy with either.
>
> Regards,
> Micah
>
>
> on 8/2/08 6:03 AM, clarifiks at [hidden email]:
>
>>
>>
>>
>> Jake, Micah and I have been discussing this before.
>>
>> The problem is that currently, there is no unified way to query the  
>> version of a plug-in so it can be used to compare the version of a
>> plug-in against a previous version of a plug-in.
>>
>> This is needed if one wants to build a FileMaker template that  
>> takes care of downloading the latest and greatest from the FileMaker
>> server, for all plug-ins currently installed, even when from  
>> different vendors.
>> It can be more or less done using specific code for each plug-in or  
>> brand, but it remains a pain to configure this, because it's always
>> done differently.
>>
>> The reason the discussion is brought to the group here is obvious.  
>> We need more plug-in developers to know about this need, and
>> recognize and respect some minimal standard.
>>
>> We are at the point where we agreed on the following ( I think):
>>
>> - 4 levels
>> - numeric
>> - a separate human readable version number
>> - 2 digits per level maximum
>> - version returned in the format aabbccdd where every letter  
>> represents a digit of the level, so versions can be easily compared.
>>
>> The proposed syntax was <plug-in>_Version ("AutoUpdate")
>> We also agreed to keep existing the version function syntax in  
>> order not to break existing solutions.
>> I hope I did not forget to mention other things.
>>
>> ----
>>
>> We were at the point where Micah proposed a separate <plug-
>> in>_AutoUpdateVersion().
>>
>> ---
>>
>> To reply to this:
>>
>> I think it's important that we rally reach a standard, and fomalise  
>> some stuff. For the moment, we seem to have obtained a level of
>> detail enough to create a standard. Let's call the current setup  
>> ( as described above ) version 0.
>> Everytime we vote to decide to change anything, we can up that  
>> number.
>>
>> Micah, ro reply to your suggestion: I think it's clean, but more  
>> work to adapt current development. Now, it's just reacting to 1 more
>> other possible parameter in an existing function, as a new  
>> function, it needs its own prototype∑etc.
>> So I'm against it - man do I hate begin negative - but maybe Jake  
>> likes the idea, in which case we just gave birth do version 1...:-)
>>
>>
>>
>
>

 

[James MacPhail]

I agree a standard for this is a good idea.

I haven't been privy to any of the back-channel discussion, but I'd suggest
something like

   <plug-in>_StdVersion( VersionOfStdVersion )

With the following idle thoughts...

'Std'Version to emphasise to a new developer that there is a "Standard"
that they should look for and follow.

The 'VersionOfStdVersion' parameter would be something like:

- "0" returns the maximum VersionOfStdVersion parameter this plugin
supports, or perhaps a return separated list of the supported parameter
choices so that gaps are possible.

- "1" returns the aabbccdd or aa.bbccdd version number as discussed

- "-" is reserved for private use

- Other than [0, 1, -] are then available for future improvements to the
standard.

- To allow for some future, more complex, parameter (eg. containing
multiple delimited values), perhaps just the first character should
indicate the requested VersionOfStdVersion, rather than the entire string.
Or perhaps the parameter should be a string of XML style key/value pairs,
but this makes the code a lot more complex for some developers, so that
might be delayed until it is required for higher functionality.

At first look, it seems to me that both aa.bbccdd and aabbccdd can be used
so long as it is self-consistent by plug-in, but I suppose making one the
standard and requiring any leading zero(s) would make it easier for someone
to use this for some other purpose.

With the name "<plug-in>_AutoUpdateVersion" I think there would be some
confusion among users wondering what it means to "AutoUpdate the
Version"... eg. "does that mean it automatically checks your website for
updates?"

I agree that variants of '<plug-in>_Version' would likely mean
incompatibility with some existing implementations, which would seem to be
much more problematic than missing the function entirely.

As simple as the code would be, public posting of ready-to-use code would
make wide adoption more likely among (new?) developers.

I don't feel strongly about any of those items, so if you guys have already
thought it all through, feel free to ignore me and/or cut me to shreds.

James

> So, the 2 ideas are:
>
> Version 0:
> <plug-in>_Version( {option} )
>
> Version 1:
> <plug-in>_AutoUpdateVersion

James MacPhail                   "Think not of engineering as art,
[hidden email]                 but of art as engineering"
Sigma Seven Systems Ltd.
[hidden email]        <http://SigmaSevenSystems.com>

[Kent Lendrum]

Hi All,

Lots of ideas coming forward, so suggest we limit the ideas, and  
perhaps do a vote ?


1) New function call  v's   parameter on existing 'Version' function

1a) <plugin>_AutoUpdateVersion()

1b) <plugin>_Version("AutoUpdate")



2) Integer v's decimal numbers

2a) 01029900

2b)  01.029900    (would need to take into account different delimiters)


Reply with your votes, and I'll do a tally.
------------------------------------------------------
Kent :  1b    &    either 2a or 2b




Pros & Cons  (my thinking anyway, admit I may be biased)
------------------------------------------------------

<plugin>_AutoUpdate
Pros
- specific use
- doesn't interfere with existing implementation of 'version' function

Cons
- another function
- will appear at the top of the list
- confusion with 'AutoUpdate' mechanism


<plugin>_Version("AutoUpdate")
Pros
- all plugins already have this function
- just add another switch
- consistent with the 'version' function

Cons
- may not comply with some implementations of 'Version'
(sorry, can't think of any more, please feel free to add)




01029900
- isn't impacted on different separators
- creating the 'AutoUpdate folder structure is cleaner  (not .'s in  
folder name)
- no clear definition of main version number


01.029900
- decimal point isn't a world wide separator, so would need to conform  
to settings
- main & sub versions are clearer

[Joe Mele]

Hi

I am lost. what is this for?

Joe Mele
www.filemakersearch.net
www.delphimagazine.net
CodeGear Technology Partner
www.fmplugin.net
www.melesystems.com
www.youseful.com
forums.youseful.net


On Mon, Aug 4, 2008 at 6:47 PM, kent <[hidden email]> wrote:

> Hi All,
>
> Lots of ideas coming forward, so suggest we limit the ideas, and
> perhaps do a vote ?
>
>
> 1) New function call  v's   parameter on existing 'Version' function
>
> 1a) <plugin>_AutoUpdateVersion()
>
> 1b) <plugin>_Version("AutoUpdate")
>
>
>
> 2) Integer v's decimal numbers
>
> 2a) 01029900
>
> 2b)  01.029900    (would need to take into account different delimiters)
>
>
> Reply with your votes, and I'll do a tally.
> ------------------------------------------------------
> Kent :  1b    &    either 2a or 2b
>
>
>
>
> Pros & Cons  (my thinking anyway, admit I may be biased)
> ------------------------------------------------------
>
> <plugin>_AutoUpdate
> Pros
> - specific use
> - doesn't interfere with existing implementation of 'version' function
>
> Cons
> - another function
> - will appear at the top of the list
> - confusion with 'AutoUpdate' mechanism
>
>
> <plugin>_Version("AutoUpdate")
> Pros
> - all plugins already have this function
> - just add another switch
> - consistent with the 'version' function
>
> Cons
> - may not comply with some implementations of 'Version'
> (sorry, can't think of any more, please feel free to add)
>
>
>
>
> 01029900
> - isn't impacted on different separators
> - creating the 'AutoUpdate folder structure is cleaner  (not .'s in
> folder name)
> - no clear definition of main version number
>
>
> 01.029900
> - decimal point isn't a world wide separator, so would need to conform
> to settings
> - main & sub versions are clearer
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Corn Walker]

Correct me if I'm wrong but my understanding is that the reason for  
this proposal was to solve the developer's need to compare plug-in  
versions in an effort to determine if there is a newer version  
available on the server.

With that being the principal need, the primary focus should be on the  
value returned by the plugin. As a plug-in consumer I want the value  
returned to me to be as simple as possible for comparison. I don't  
want to parse the results of the function, I want a single numeric  
value that I can compare to another numeric value. A float would be  
ideal here; it would allow me to say positively that version 3.0234 is  
newer than version 3.0101 (or 3,0234 is newer than 3,0101 for our  
european friends). How the plug-in developer arrives at that version  
number is immaterial to me, provided the numbering scheme always  
increments.

Secondary to this use, and of relatively less concern, is the function  
prototype itself. Whether I call the function as 'MyPlugin_Version  
( "special parameter" )' or 'MyPlugin_SpecialVersion ()' is of less  
concern. Certainly it would be useful if all plug-in developers  
adopted a single convention but the penalty for not doing so is that I  
must lookup the convention used to get the special version number.

To that end, I don't see much here that is controversial. Plug-in  
developers should create a version numbering scheme that makes it  
trivial to compare version numbers. The principal issue, then, is to  
determine whether there is some compelling need for a version number  
format that is less trivial than the simple float representation I've  
presented above. Everything else involving a standard prototype is  
just gravy to me.

Cheers,
-corn


Corn Walker
The Proof Group
http://proofgroup.com/

[Kent Lendrum]

Hi Joe,

A discussion has been occurring, initially between a few plugin  
developers, but now moved to this list, regarding standardising how a  
plugin returns a version number.

Specifically, the goal was to make a consistent way for end users of  
'All' plugins to get the respective plugin version.

It was identified that amongst the different plugin developers,  we  
each have different ways of reporting this information.

some examples are
<plugin>_Version()
<plugin>_Version("-Number")
<plugin>_Version(2)
etc.


The results from the above calls vary.
eg.
Plugin Name v1.2v3
Plugin Name v1.2.34b123
Plugin-Name 1.2
3020
3.02
1.2.3
1.2v3


This makes it difficult for the end user to use a common approach in  
determining the plugin version as a number, which can then be used in  
a simple comparison.
eg.  getasnumber ( <plugin>_Version("Number") )  <  1.2


As a result of these discussions, different vendors have proposed  
different approaches.

What I have done, is attempt to limit this down to two possibilities  
(for the function call itself,  and the output returned)



The ultimate goal is,  all plugin vendors will end up with a numeric  
version returned which the end user can use to easily compare versions.


Kent.


On 5/08/2008, at 12:09 PM, Joe Mele wrote:

> Hi
>
> I am lost. what is this for?
>
> Joe Mele
>
> On Mon, Aug 4, 2008 at 6:47 PM, kent <[hidden email]> wrote:
> Hi All,
>
> Lots of ideas coming forward, so suggest we limit the ideas, and
> perhaps do a vote ?
>
>
> 1) New function call  v's   parameter on existing 'Version' function
>
> 1a) <plugin>_AutoUpdateVersion()
>
> 1b) <plugin>_Version("AutoUpdate")
>
>
>
> 2) Integer v's decimal numbers
>
> 2a) 01029900
>
> 2b)  01.029900    (would need to take into account different  
> delimiters)
>
>
> Reply with your votes, and I'll do a tally.
> ------------------------------------------------------
> Kent :  1b    &    either 2a or 2b
>
>
>
>
> Pros & Cons  (my thinking anyway, admit I may be biased)
> ------------------------------------------------------
>
> <plugin>_AutoUpdate
> Pros
> - specific use
> - doesn't interfere with existing implementation of 'version' function
>
> Cons
> - another function
> - will appear at the top of the list
> - confusion with 'AutoUpdate' mechanism
>
>
> <plugin>_Version("AutoUpdate")
> Pros
> - all plugins already have this function
> - just add another switch
> - consistent with the 'version' function
>
> Cons
> - may not comply with some implementations of 'Version'
> (sorry, can't think of any more, please feel free to add)
>
>
>
>
> 01029900
> - isn't impacted on different separators
> - creating the 'AutoUpdate folder structure is cleaner  (not .'s in
> folder name)
> - no clear definition of main version number
>
>
> 01.029900
> - decimal point isn't a world wide separator, so would need to conform
> to settings
> - main & sub versions are clearer
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

[Micah Woods]

on 8/4/08 9:25 PM, Corn Walker at [hidden email] wrote:

> Correct me if I'm wrong but my understanding is that the reason for
> this proposal was to solve the developer's need to compare plug-in
> versions in an effort to determine if there is a newer version
> available on the server.

Yes, a simple, standard way to compare versions for the purpose of
determining whether or not auto-update is needed.

> With that being the principal need, the primary focus should be on the
> value returned by the plugin. As a plug-in consumer I want the value
> returned to me to be as simple as possible for comparison. I don't
> want to parse the results of the function, I want a single numeric
> value that I can compare to another numeric value. A float would be
> ideal here; it would allow me to say positively that version 3.0234 is
> newer than version 3.0101 (or 3,0234 is newer than 3,0101 for our
> european friends). How the plug-in developer arrives at that version
> number is immaterial to me, provided the numbering scheme always
> increments.

I like float too. Integer is OK but I think it's likely to be confusing to
some. Not sure if period or comma matters, seems like this could be left up
to the developer. The math will work either way.

> Secondary to this use, and of relatively less concern, is the function
> prototype itself. Whether I call the function as 'MyPlugin_Version
> ( "special parameter" )' or 'MyPlugin_SpecialVersion ()' is of less
> concern. Certainly it would be useful if all plug-in developers
> adopted a single convention but the penalty for not doing so is that I
> must lookup the convention used to get the special version number.

I actually think the prototype is what this is all about. We all have
version functions that allow you to calculate auto-update comparisons, we
just don't have a standard.

I really like the way Dacons has done their version function. It allows you
to get the version number and the product name which are both required for
the call to FMSAUC_UpdatePlugIn. They use the flag "Version" to return the
version number which actually makes more sense to me than "AutoUpdate". They
use ³Product² to return the product name.

For example:

<plug-in>_Version( "Version" ) // returns numeric version for comparison

<plug-in>_Version( "Product" ) // returns name of the plug-in

I can then do this:

FMSAUC_UpdatePlugIn( <plug-in>_Version( "Product" ) & ³ ³ &
<plug-in>_Version( "Version" ) )

Since FileMaker¹s auto-update manual uses ³plug-in-name², I¹d use ³Name²
instead of ³Product².

So for our plug-in, the manual would read:

PHP_Version( {option} )

This function returns version information and can be used to determine
whether or not auto-update is needed. Using PHP_Version with no parameters
will return all plug-in information.

To return the plug-in version, pass in the parameter ³Version². This will
return a numeric value that can be used to determine if the installed
version needs to be updated.

To return the plug-in name, pass in the parameter ³Name².

To return the PHP version included in the plug-in, pass in the parameter
³PHPVersion².

To return the copyright information, pass in the parameter ³Copyright².


My apologies for introducing yet another idea.

-- Micah

[Kent Lendrum]

Hi Micah,


I like the concept, and think this is the closest to an ideal solution  
yet.


This won't work for AutoUpdate however...

1) If the plugin isn't currently installed  (hence will return ?)

2) This will try to AutoUpdate the current version,  when one would  
normally be wanting to update to a newer version.

or did I miss something ?

Kent.




> I can then do this:
>
> FMSAUC_UpdatePlugIn( <plug-in>_Version( "Product" ) & “ “ & <plug-
> in>_Version( "Version" ) )

[Koen Van Hulle]

On 05 Aug 2008, at 03:50, kent wrote:

>
> As a result of these discussions, different vendors have proposed  
> different approaches.
>
> What I have done, is attempt to limit this down to two possibilities  
> (for the function call itself,  and the output returned)
>
> The ultimate goal is,  all plugin vendors will end up with a numeric  
> version returned which the end user can use to easily compare  
> versions.
>
>
> Kent.

Especially, to implement the Auto update functionality of FileMaker.  
If you make use of a lot of plug-ins by different vendors it can be  
though to manage this all.

To answer your question (and I'm just a FileMaker Developer, not a  
plug-in builder):
1) New function call  v's   parameter on existing 'Version' function
1a) <plugin>_AutoUpdateVersion()
2a) 01029900


Koen


______________________________
Koen Van Hulle
SHpartners
[e] [hidden email]
[m] [phone]
[w] http://www.shpartners.com
[i] [phone]



 

FileMaker 7, 8 and 9 Certified Developer

http://blog.myfmbutler.com

[Jesse Barnum-2]

I am skeptical that standardizing on a version # scheme is going to  
dramatically improve the uptake rate on the auto-update feature. I am  
amazed at how many developers, even intermediate-advanced ones, think  
that auto-update is too complicated for them to bother with (and  
they're right), and that has nothing to do with figuring out which  
function to call to get the version #. I think a feature change in  
FileMaker Server which would just automatically take care of auto-
updating is the only way to change the "no plugins here" mentality of  
many FileMaker users and developers.

If everybody who is participating in this discussion were to approach  
the powers that be at FMI with a united plan, I really believe that  
they will listen and incorporate this feature. If that happened, I  
think that the overall plugin market would increase by at least  
double and probably much more than that.

I don't want to hijack the thread, so I'll leave the details of the  
feature request alone for now, but I'd love to know if anybody else  
is interested in discussing the specifics and presenting a plan to FMI?

--Jesse Barnum, President, 360Works
http://www.360works.com 770-234-9293
FBA Platinum, FileMaker 8 Certified
== SuperContainer: A Better Container Field ==

[Jake Traynham]

Peter Wagemans wrote:

> It all makes sense. So we're at version 1 with
> <plug-in>_AutoUpdateVersion() without any parameters.
>
> Jake wrote:
>> However, I do have one other slight change to your proposal.  You said
>> to have the number format be aabbccdd, but I would actually prefer
>> aa.bbccdd, and not just because that's how I currently do it. :)  It
>> makes sense in my head to have the major version number be the whole
>> number part while the minor/update/beta part be the fractional part.
>> This seems to be how other version number schemes seem to work.
>
> Jake, have you considered that a big part of the world does not use a
> dot as the decimal separator?
> -- peter

Doh!  No, silly me.  Okay, no decimal then.  And it shouldn't be a
problem for our existing customers since we've decided to do the
separate function.

One clarification though, should the first (major) number be zero padded
like the rest, just to be clean?  For example,

Version: 4.1.13b7
Auto Update: 04011307

That way it's always 8 characters long.  Obviously it wouldn't matter in
a mathematical comparison, but it would be easier if someone wanted to
extract individual parts of it for some reason.

Thanks ... and sorry for being a self-centered American :)

Jake

--
Jake Traynham
Owner, CNS Plug-ins
http://www.cnsplug-ins.com/

[Peter Wagemans]

On 5-aug-08, at 05:12, Micah Woods wrote:
> <plug-in>_Version( "Product" ) // returns name of the plug-in

For the Auto-Update mechanism, the server looks for a folder that  
carries the name that you use in the first parameter in the  
FMSAUC_UpdatePlugIn() function.
So you can call that folder whatever you want to call it, and that  
specific version parameter as Dacons does is not really needed.
In my daily FileMaker development work, I'm in control of the server  
folder situation, so I decide myself how the folders are named, and  
know about those names in my AutoUpdate records.
It's nice to have the plugin function propose a name, but I consider  
this as an optional feature.

Regarding the version digits, the server uses that in the second  
parameter in the FMSAUC_UpdatePlugIn() function.
To be really sure it will not interfere with the OS's name space for  
folders, please let's not use any separators, because the plug-in has  
to be found in a sub-folder carrying those digits as a name.
( no need to apologise Jake...:-) I'm sure us europeans make a few  
eyebrows raise as well sometimes ... ; | )

On 5-aug-08, at 13:27, Jesse Barnum wrote:
> If everybody who is participating in this discussion were to approach
> the powers that be at FMI with a united plan, I really believe that
> they will listen and incorporate this feature. If that happened, I
> think that the overall plugin market would increase by at least
> double and probably much more than that.

People at FileMaker are reading this list. I know even Clay does. But  
let's be practical and not hold our breath while waiting for a new  
API. The problem exists now, and should be solved ASAP. If FileMaker  
comes up with a better API in a few years from now, I will be very  
happy. But that's about it.
Adding this very simple function solves the problem. Now.
I understand Jesse's skeptisism, but it takes as much effort to  
propose a standard to FileMaker ( and hope for the best ) as to agree  
on a standard among us ( getting things done ).
I'm skeptical as well, but in a slightly different way.

In reaction to other suggestions for more parameters:
Let's not take it to far. The only thing we need is a unified response  
when performing the <pllugin>_AutoUpdateVersion(). That will do the  
job. It's really the only functionality needed.
If a developer wants to add additional OPTIONAL parameters to provide  
a superset of functionalities, that's OK, as long as it does not  
interfere with the function call without parameters.
Optional parameters could be <plugin>_AutoUpdateVersion("Name"),  
<plugin>_AutoUpdateVersion("blah") or whatever, the function would  
still remain compatible with the agreed upon simple standard.

To answe to Kent's poll:
1) New function call v's parameter on existing 'Version' function
1a) <plugin>_AutoUpdateVersion()
2a) 01029900

The reason for my choices:
- a new function does not interfere with any code I've written earlier  
for the existing <plugin>_version function, so I will not be  
introducing new bugs there
- "AutoUpdate" says what the function is for, I know other names will  
also work, but let's not loose ourselves in choosing the absolutely  
perfect name
- I prefer the trailing zero for a level 1 version digit < 10, it  
emphasises the structure and does not interfere with version  
comparisions, as Jake said already.

PS: I like the suggestion made by ( who was it? ) to cook up some  
sample code. It always takes me ages to write just a few lines of c  
code.
 

[Joe Mele]

ok cool.

I give a build date now as well part of the version. Just in case a later
build of the same version.   minor stuff bug fixes cosmetic- fixing spelling
etc
 Example  - 2008April15 this was built on April 15 2008 etc

ySQL_Version("internal") -> "2008July19a FM9" (FM9 is lib compiled against)
ySQL_Version("")  ->    "v2.3"

Joe Mele

www.filemakersearch.net
www.delphimagazine.net
CodeGear Technology Partner
www.fmplugin.net
www.melesystems.com
www.youseful.com
forums.youseful.net


On Mon, Aug 4, 2008 at 9:50 PM, kent <[hidden email]> wrote:

>  Hi Joe,
> A discussion has been occurring, initially between a few plugin developers,
> but now moved to this list, regarding standardising how a plugin returns a
> version number.
>
> Specifically, the goal was to make a consistent way for end users of 'All'
> plugins to get the respective plugin version.
>
> It was identified that amongst the different plugin developers,  we each
> have different ways of reporting this information.
>
> some examples are
> <plugin>_Version()
> <plugin>_Version("-Number")
> <plugin>_Version(2)
> etc.
>
>
> The results from the above calls vary.
> eg.
> Plugin Name v1.2v3
> Plugin Name v1.2.34b123
> Plugin-Name 1.2
> 3020
> 3.02
> 1.2.3
> 1.2v3
>
>
> This makes it difficult for the end user to use a common approach in
> determining the plugin version as a number, which can then be used in a
> simple comparison.
> eg.  getasnumber ( <plugin>_Version("Number") )  <  1.2
>
>
> As a result of these discussions, different vendors have proposed different
> approaches.
>
> What I have done, is attempt to limit this down to two possibilities (for
> the function call itself,  and the output returned)
>
>
>
> The ultimate goal is,  all plugin vendors will end up with a numeric
> version returned which the end user can use to easily compare versions.
>
>
> Kent.
>
>
> On 5/08/2008, at 12:09 PM, Joe Mele wrote:
>
> Hi
>
> I am lost. what is this for?
>
> Joe Mele
>
> On Mon, Aug 4, 2008 at 6:47 PM, kent <[hidden email]> wrote:
>
>> Hi All,
>>
>> Lots of ideas coming forward, so suggest we limit the ideas, and
>> perhaps do a vote ?
>>
>>
>> 1) New function call  v's   parameter on existing 'Version' function
>>
>> 1a) <plugin>_AutoUpdateVersion()
>>
>> 1b) <plugin>_Version("AutoUpdate")
>>
>>
>>
>> 2) Integer v's decimal numbers
>>
>> 2a) 01029900
>>
>> 2b)  01.029900    (would need to take into account different delimiters)
>>
>>
>> Reply with your votes, and I'll do a tally.
>> ------------------------------------------------------
>> Kent :  1b    &    either 2a or 2b
>>
>>
>>
>>
>> Pros & Cons  (my thinking anyway, admit I may be biased)
>> ------------------------------------------------------
>>
>> <plugin>_AutoUpdate
>> Pros
>> - specific use
>> - doesn't interfere with existing implementation of 'version' function
>>
>> Cons
>> - another function
>> - will appear at the top of the list
>> - confusion with 'AutoUpdate' mechanism
>>
>>
>> <plugin>_Version("AutoUpdate")
>> Pros
>> - all plugins already have this function
>> - just add another switch
>> - consistent with the 'version' function
>>
>> Cons
>> - may not comply with some implementations of 'Version'
>> (sorry, can't think of any more, please feel free to add)
>>
>>
>>
>>
>> 01029900
>> - isn't impacted on different separators
>> - creating the 'AutoUpdate folder structure is cleaner  (not .'s in
>> folder name)
>> - no clear definition of main version number
>>
>>
>> 01.029900
>> - decimal point isn't a world wide separator, so would need to conform
>> to settings
>> - main & sub versions are clearer
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>
>
>

[Micah Woods]

Hello Kent,

Uhhh, no you didn¹t miss anything, just a mistake on my part.

-- Micah


on 8/5/08 12:08 AM, kent at [hidden email] wrote:

>  
>  
>
> Hi Micah,
>
>
> I like the concept, and think this is the closest to an ideal solution yet.
>
>
> This won't work for AutoUpdate however...
>
> 1) If the plugin isn't currently installed  (hence will return ?)
>
> 2) This will try to AutoUpdate the current version,  when one would normally
> be wanting to update to a newer version.
>
> or did I miss something ?
>
> Kent.
>
>
>
>
>> I can then do this:
>>  
>>  FMSAUC_UpdatePlugIn( <plug-in>_Version( "Product" ) & ³ ³ &
>> <plug-in>_Version( "Version" ) )
>
>  
>    

[Jake Traynham]

Peter,

> - I prefer the trailing zero for a level 1 version digit < 10, it
> emphasises the structure and does not interfere with version
> comparisions, as Jake said already.
>

You mean _leading_ zero, right? :)

Jake

--
Jake Traynham
Owner, CNS Plug-ins
http://www.cnsplug-ins.com/

[Peter Wagemans]

Oops. Indeed. Sorry. It's been a rough day...:-)

On 5-aug-08, at 21:02, Jake Traynham wrote:

> Peter,
>
> > - I prefer the trailing zero for a level 1 version digit < 10, it
> > emphasises the structure and does not interfere with version
> > comparisions, as Jake said already.
> >
>
> You mean _leading_ zero, right? :)
>
> Jake
>
> --  
> Jake Traynham
> Owner, CNS Plug-ins
> http://www.cnsplug-ins.com/
>
>

 

[Nicholas Orr]

G'day all,

I'm not a plugin developer, just an interested bystander - are you  
also taking into account what you do with beta versions?  I've never  
figured out how to compare 2.1.2b1 with 2.1.2 and make the second one  
come after.  Is there a way you're doing this currently and will your  
new suggestions take this into account?

 From the perspective of a plugin implementer, the best thing I think  
plugin developers can do to make it easier is to supply a zipped  
AutoUpdate folder for their new versions of their plugins.  Would make  
lots of the issues go away.  My 2c.

Cheers,
Nick