Ola,
Thanks for your input, it is good not to be talking completely to myself.
;-)
> There are different use cases for versioning, and I think it would be
foolish to meet them all in the same package.
I assume this statement is not a generalization, but comes from my previous
statement -- summarized: "using versions to debug environments requires
minimal dependencies, or is self-defeating". If not, please clarify. When
you says "one package" I am assuming you mean one distribution (JAR) and not
one Java package. I agree with the latter, but not the former.
As I see it, one creates a framework, unit tests, code samples (public
tests/code-based document for those that like that), one creates tools, one
creates GUIs and more (as optional extras). Nothing portrays a vision better
than some neat working examples of it, that a user can run and see w/
minimal effort. A distribution can contain some or all of these in separate
java packages without being foolish (IMHO). A few well positioned ant
<available>s and it can tolerate developer environments. As I see it the
framework grows as large or small as market forces (i.e. users/user
feedback/contributions) and common sense dictate. Only if it gets too
unwieldy, including if it gets too many dependency, would one split it. I
see no reason not to start by setting the sights high.
Getting back to the main topic: I suspect that you have a "my code plus
legacy code primary focus" whereas I have a "my code plus Apache code plus
future code primary focus". (Not wanting to speak for you, or say you don't
have a wide vision, this is just my take from what I read.) I recognize that
legacy code never seems to goes away, however I firmly believe that
versioning "somebody else's code" is at best risky proposition, and possibly
more often wrong than right, and quite possibly "foolish" ;-). I also
believe there are far more requirements and different approach than you
suggest. Thankfully though -- using your suggestion of a reflection-only
approach -- I think we can agree to disagree on all these aspects whilst
both working in the same general direction...
If we (somebody) can gain acceptance for a convention, then if we agree to
differ then I can write my code for manipulating versions/constraints, you
can write yours (I will help if I were to be invited), and we can both work
on those "branded" versions w/o restriction or much overlap. Good healthy
competition w/ a standard as the foundation so as not to cause interruption
to the masses. :)
I believe the convention ought be along the lines of:
1) The class naming convention: ( .version. keeps it separate/out of the
way.)
{primary package path}.version.Version.class
Saves class loaders being inefficient as they search.
2) A single method or public field
String getVersionString()
3) The string format
I guess I'd have to propose as documented here, if it could reach wide
enough acceptance.
http://jakarta.apache.org/commons/versioning.html
If not, we've need a number of "version format" choices (and perhaps even
"version versions".)
i.e. Something like:
package mystuff.version;
public class Version
{
// For version of version...
public static final String VERSION_FORMAT = "Jakarta
Apache Commons";
public static final String VERSION_VERSION = "1.0-A1";
// Major = 3, Minor = 0, Point = Beta,
public static final String VERSION_STRING = "3.0-B1";
// An *optional* interface, if it exists it is used, else fall back
// to the field VERSION_STRING;
public String getVersionString()
{
// Lame example, could be a wrapper to external version.
return Version.VERSION_STRING;
}
}
If folks are game, I'd happily write something up, and post it here. I am
sure this example above is incredibly over simplified, and doesn't include
all that folks might like, but it is for starting discussion purposes.
Coping with extensions (enhancements -- i.e. new version of version, as you
said) would have to be carefully considered. Nothing is to stop us from
allowing optional extras, such as aggregating versions of sub-components and
such.
Since I am no longer asking for a home, or for access permissions, or a
project, merely requesting to contribute a document, perhaps I can engage
any thread stalkers. Do folks have opinions?
Thanks for your input.
regards,
Adam
-----Original Message-----
From: Ola Berg [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 24, 2003 2:21 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [version] reflection-based [was:PROPOSAL Commons-Version]
There are different use cases for versioning, and I think it would be
foolish to meet them all in the same package.
Users
=====
Developers wanting to version their classes
Developers wanting to version other's classes
Developers with simple needs to check version
of a class before using it
Developers with advanced needs to check version
of a class before using it
I am not sure of the difference between "simple" and "advanced" in the two
latter cases.
Approaches for versioning
=========================
Declare a coding-pattern
No package dependencies involved.
Implement an interface
Perhaps from a very very simple jar
Create a version-class that will put
version on an existing class
A more advanced versioning toolkit containing
abstractions of rules etc
Approaches for checking versions
================================
Simple tool (isVersionAbove(), isCompatibleWith( version))
Small version-util jar
Advanced integration with Discovery
I think that the advanced stuff should
be integrated [in | with] Discovery
Discovery is a candidate, since [version] would solve a problem wihtin
Discovery's problem scope (finding the right resource from many candidates).
My 2 cents...
/O
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
