You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bsf-dev@jakarta.apache.org by "Rony G. Flatscher" <Ro...@wu-wien.ac.at> on 2006/01/16 08:40:34 UTC
A suggestion on versioning information ....
Hi there,
if installing or exploiting bsf it becomes important to be sure to know
with which version of BSF one deals. E.g. if installing a new version of
BSF, how would one be able to identifiy the exact version of the
presently installed package?
One way to solve this would be to introduce a static field named e.g.
"version" which would carry the exact version information. One
possibility here would be to use a string in the form "abb.yyyymmdd",
where "a" is the major version number, "bb" the minor version number,
and "yyyymmdd" represents the date in sorted order (four digit year, two
digit month, two digit day). This makes it rather easy to parse the
version information from any (scripting) programming language, as
usually every language is able to deal with a string value.
What do you think?
Regards,
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: A suggestion on versioning information ....
Posted by "Rony G. Flatscher" <Ro...@wu-wien.ac.at>.
Ulf Dittmer wrote:
> Not so much for an end user running BSF-based code, but for the
> developers of BSF engines. An engine may support more than one version
> of BSF, but differentiate its behavior based on the capability of BSF.
>
> On 22.01.2006, at 06:37, Henri Yandell wrote:
>
>> Basically, is there a need to know the version at runtime?
>
In addition, it makes it easier than going via the manifest file, which
in cases where BSF got repackaged may not be available or contain any
further BSF-related version information at all. (Using version infos
and/or build dates as part of file-names is rather fragile and hence
error-prone.) Having an easy way to access that vital information may
come in very handy as well for some use-cases, e.g. is there a newer,
compatible - same major version number as the one which is distributed
via the app - BSF already installed on the system etc.
Getting the version info from a public static method located in
BSFManager should make it easy on anyone to get at the "real" version
number.
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: A suggestion on versioning information ....
Posted by Ulf Dittmer <ul...@ulfdittmer.com>.
Not so much for an end user running BSF-based code, but for the
developers of BSF engines. An engine may support more than one version
of BSF, but differentiate its behavior based on the capability of BSF.
On 22.01.2006, at 06:37, Henri Yandell wrote:
>
> Basically, is there a need to know the version at runtime?
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: A suggestion on versioning information ....
Posted by Henri Yandell <fl...@gmail.com>.
On 1/16/06, Rony G. Flatscher <Ro...@wu-wien.ac.at> wrote:
> Hi there,
>
> if installing or exploiting bsf it becomes important to be sure to know
> with which version of BSF one deals. E.g. if installing a new version of
> BSF, how would one be able to identifiy the exact version of the
> presently installed package?
Okay, dumb answer: Look at the jar filename? :)
Failing that, the META-INF/MANIFEST.MF.
Basically, is there a need to know the version at runtime?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
Re: A suggestion on versioning information ....
Posted by "Rony G. Flatscher" <Ro...@wu-wien.ac.at>.
Hi Ulf:
>>One way to solve this would be to introduce a static field named e.g.
>>"version" which would carry the exact version information.
>>
>>
>
>This sounds like a good idea. Just don't make the field final, or clients
>compiled against one version will not be able to distinguish it from
>another version. Some libraries do that, and the only way around it is to
>use reflection on the field.
>
>
Here are the code snippets from my present version of "BSFManager.java":
// version string in the form of: "abb.yyyymmdd",
// where "a" is the major version number, "bb" the minor version number,
// and "yyyymmdd" represents the date in sorted order (four digit year, two digit month, two digit day)
protected static String version="204.20060117";
/** Returns the version string of BSF.
*
* @return version string in the form ""abb.yyyymmdd"" where
* "a" represents the major version number,
* "bb" the minor version number,
* "yyyy" four digit year,
* "mm" two digit month, and
* "dd" two digit day.
* @since 2006-01-17
*/
public static String getVersion()
{
return version;
}
So access to the version string should be via its get-method
"getVersion()".
Any thoughts, ideas, further comments?
Regards,
---rony
Re: A suggestion on versioning information ....
Posted by Ulf Dittmer <ul...@ulfdittmer.com>.
Hi everyone-
> One way to solve this would be to introduce a static field named e.g.
> "version" which would carry the exact version information.
This sounds like a good idea. Just don't make the field final, or clients
compiled against one version will not be able to distinguish it from
another version. Some libraries do that, and the only way around it is to
use reflection on the field.
Cheers,
Ulf
---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org