Hi Reed (and others)
<soapbox>
I think there are good reasons to change the version string, and now is
a good time to do a "dramatic" change, if this can be called that.
Im probably more interested in debating the new solution so if anyone
has a better idea how to do this, or can suggest some improvements, or a
less invasive way of making the change Im interested.
What worries me is that the net result of this which is a 10minute job
will be 60 emails over the issue, everyone will get tired and nothing
will happen. In six months time somone will suggest this or a similar
change and we'll go through the same debate again, again with the same
null result.
As I said before, while I think that it's important to consider issues
carefully, we can't do endless research on every tiny change before we
act. Otherwise, much as is happening - nothing happens. On the one
hand we have Jim in ib-architect saying, dump interclient, go c++, drive
threading deep into the engine, etc, and here we're having trouble
change a version string. Change will cause trouble, sometimes we have
to live with it, hopefully the advantages will outweigh the problems.
Remember if/when it fails or we find there is a integration problem with
someone elses tool, we can always back out the change, modify it or
suggest they change their tool.
To have gone through all the debate we had to decide on version "1.0", I
think that to then turn around and keep the version string as "6.0.1" to
be compatible with the Inprise release would just confusing everyone
(although I know Im suggesting changing it a bit more than that).
</soapbox>
<reason>
Althought I thought some of this should be obvious, and I'd probably
like to spend time on the "what a better way is" debate this is why I
think we should change (in addiiton to reasons mentioned in stuff posted
previously):
InterBase was closed shop, all work was carried out by developers in the
know, and release procedures controlled. Customers spoke to their local
Cognos/Ashton Tate/Inprise distributor if they wanted to know anything,
like when is the next version or can I get the latest beta copy. Nobody
actually worked on source except registered people and they worked on it
for a living. Users could also probably also look up their documentation.
In our world development is spread over lots of people all over the
place with varying knowledge of the codebase. People are going to build
this stuff from source who don't really know or care who Inprise or
Firebird are. People will build and tinker with development version in
their own play pen for months without refreshing them from the latest
source. Support questions are going to be mainly solved/discussed
through email. And we have minimal documentation.
So in my mind the current environment has much more call than the
original inhouse development environment for a version string that is a
very clear and easily distinguishable.
So in the current string.
ISQL Version: LI-T6.0.0.627
The Release Code. The T,X, B or V are not bad but are I'd like
something obvious - so thats why I suggested using a string such as
Test/Beta/etc. An example of how the T doesn't stand out is that the
linux version of the ISC release was put out with a "B" beta rather than
a "V" and noone noticed (I know that they had enough on their hands at
that time). But if even the original developers missed it and I
certainly never paid any attention to it, then newcomers I think need a
clearer indication of the status of a Firebird version.
Now Build number. The Build number is a problem as it is easily
mistakable for a version refinement. In some ways this is ok, but again
its always nicer to be explicit. Currently It is distinguishable only
be being so large it couldnt be a version refinement. So it needs to be
distinguished someway (often this is done like T1.0.0 (627) or even
T1.0.0 (Build 627).
And minor release numbers. Version 6.0 will undergo several dev
releases (milestone 1, milestone 2...) , test releases, beta releases
(beta1, betta2) maybe release candiate 1, and then several production
releases.
(Im guessing a bit here how ISC used the current version strings but
assume it was as follows) I guess the progress of a 1.0 release would be
each release of test version would be T1.0.0 (Build 10) , T1.0.1 (Build
34) etc. Then when we get to a production release the minor number
would go back to zero and it will be V1.0.0 (Build 57).
Here then the status of T1.0.1 is a bit unclear. Was it an incremental
test release prior to V1.0.0 or is it a test release of an upcomming
V1.0.1 release. As I say since I wasn't there within InterBase corp. I
don't really know how it was used, but the point being again that the
relationship is not obvious.
The reason for the confusion is that the "T" or "V" is at the front of
the equasion so the string does not vary in a simple alpabetic order
sort. The "T" "V" build states etc are really variations on constant
release version 1.0 with the additional .0 or .1 being subvariations of
those build states.
So ordering the version string something like V1.0.DEV1, V1.0.BETA1, or
V1.0.RC1 allows for several releases at each step in the cycle without
confusing the order of minor release numbers.
The machine prefix is basically OK. In "LI-T6.0.0.627" then "LI" means
linux. Although I didn't really know this until I looked at the code.
Nowadays people arnt as tight on disk space and if we were starting
again then it might be worth cosidering the full word, "Linux", "Win32"
etc but it's not something that is going to cause a real problem.
The FB prefix. I think something like this is important, Since there
are two, IB and FB, streams here, it's important in my mind that there
is a simple tag that quickly identifies which stream they are using.
These version tags are often quoted in email and it's a pretty poor
substiture to have to ask someone are you running IB or FB you can find
out by geting the version number and if its 1.X then its FB or if its
3.X 4.X 5.X 6.X then it's probably IB. (If we use the same version
numbers, as we are currently, it'd be a nightmare).
So in final:
I'd like something like: "FB Linux-V1.0.Test1 (Build 123)"
But am happy to compromise to: "FB LI-V1.0.Test1.123" or something
similar. Suggestions welcome.
</reason>
I hope that convinces you that I've spent some time thinking about the
issue, and that I don't suggest it lightly. Although I don't agree with
change for changes sake, for progress to happen change needs to take place.
What follows is some commentary on Reeds original reply. It's a bit
more chatty in style.
reed mideke wrote:
> My position is that we need to consider how any change we make
> will affect end users of the software. And if a change does not
> have value to end users, there is no point in doing it.
> (making the code more readable so that we can work on it
> obviouslly DOES have value to end users. Fixing warnings is
> the same. Changing version NUMBERS when something changes
> is of obvious benenfit to end users.)
As stated above I think it does have benefits.
> As primitive as it is, the version string is an interface
> visible to existing software. Unless we are sure that it does
> NOT impact existing software, we need to exercies caution.
We can never be sure, but I'd be supprised if the dependacy was deep.
For example in interbase itself the changes are very minor - and one
would have expected that to have the most problems.
> As an example, through idiot policy at inprise, we changed
> the interbase registry about 4 times. A very good example of
> "this is just a string" and we want it to say Borland Interbase
> or InterBase Software Corp or whatever. This caused thousands
> of customers grief, did not benefit a single one. It made some
> idiot executives happy for a few seconds, before they went on to
> look for new and better ways to make their product suck.
I agree this sort of thing goes on quite a bit, changes get driven by
marketting or brand image because blue is a power color expressing
security and strength.
Just think of all the poor sods in Inprise who have spent ages changing
strings/registry settings in code from Borland to Inprise and now
changing it back to Borland. Are they doing it because they have a
large stock of old preprinted paper and business cards? The chaps that
produce stationary and must be rubbing their hands with glee.
>> I also had a fairly decent look when we did the survey thing about
>> what files would be affected, and it seemed within the Firebird/interbase
>> context the dependencies were fairly simple. Outside this relm, I think
>> they can cope.
>
> Outside this realm meaning the people who USE firebird ? Or do you mean
> the Inprise ?
I meant third party tools, that pick up the version number and split it
up. Like I said it should be fairly trivial to code around if someone
does this.
>>> So what can be done to avoid these problems with windows installations?
>>> If this is really an issue, we will get problems anyway.
>>
> The problem is this:
[snip -many good points about widows mixed FB/IB installs]
> The long term solution is to come up with a system where firebird
> does NOT share any resources with interbase. This shouln't to hard
> to do, and (if we make it configurable) will allow interbase to
> be truely embedded. (that is, an application that uses interbase
> can install the interbase in it's own directory structure, using it's
> own ports and memory mapped files, it's own magic header on the DB,
> with it's own names, and no one will know)
I think mixed installs on the same box are going to be a problem,
however we do it. What we eventually do depends on whether IB surives
in Inprise, if the trees are merges/synced etc. Although our problems
are extreme, clashes of these resources are not unknown between
products, who accidently choose the same dll/library name.
Changing version numbers is a first (small) step in trying to reduce
the conflicting overlap with IB (maybe they'll change their dll names ;-).
> An interem solution would be to make a simple program (or maybe
> just a text list) that allows the user to COMPLETLY remove
> firebird or interbase.
The Firebird linux installs I wrote does this and puts the prior files
into a .tar.gz file (from /opt/ /usr/lib /usr/include etc). The Inprise
IB install renames the include files and libraries with a timestamp
suffix but leaves them in /usr/include /usr/lib.
>> SO WHAT DO WE DO?
>>
>> The change as outlined a bit below should be fairly simple to change to V1.0Test0 as in:
>>
>> #define IB_MAJOR_VER "1"
>> #define IB_MINOR_VER "0"
>> #define IB_REV_NO "Test0"
>> #define IB_BUILD_NO "1"
>>
>
> Turning revno into a string does not strike me as a good idea.
> Anyone parsing that string expects it to be a number.
Anyone parsing this string should probably be shot, or take the 10sec to
change their code.
BTW I don't really care if we add another #define here. The macro by
itself is NOT used within interbase so it will case no problems, it is
only the (currently theoretical) possibility that someone parses the
string (length is more likely to be the problem).
> If you set the version to 1, interbase installs (even 4.2) will
> always over-write our installs. This might be preferable to
> the current situation.
Yes, on windows. The only solution is to the mixed IB/FB on the same
box is NOT to do a mixed install, their is no other solution.
>> The enteries in licence.h can then be set as constants (rather than changing
>> all the time from B to V etc) and I agree that it would be nice to include
>> the FB prefix here to distinguish us from our parent (Firebird - daughter of
>> interbase?).
>>
>
> I absolutly agree that the B, V etc should be a single macro.
At least we agree on something ;-).
>> So in licence.h we change them to the following format.
>>
>> #define IB_PLATFORM "FB_LI-V" /* Linux on Intel */
>>
>> The full string would be something like "FB_LI-V1.0Test0.1"
>>
>
> And god help any program out there that assumes the platform
> string is at most three bytes, or that the version number is
> a number.
Reed, we need to change something.
Boy, I'd hate to be trying to argue the case with you as to why we
should change from using 8.3 file names. or if we should be going from
DOS to Win32 - let alone from Win32 to Linux/FreeBSD. It sounds like it
would be a hard sell :-).
Cheers
Mark
|
