I am sorry I think you are way out of line here, not only are you
bringing up things discussed on the closed beta list which you did sign
up for keeping there and only there. But also are you taking a very
insignificant ant and making a elephant out of it. For god sake we are
talking about version numbers 1.3.2, how complicated is it ? Should
there only be one EXIF meta tag reader in the world ? (To be 100% sure
its compatible ? (and no EXIF is not 100% compatible from reader to
reader), but those are insignificant meta tags like the version info.
If you are afraid to go out of business because someone might in the
future stop making a version tag reader then I really wonder what kind
of business it it ?
I am sorry I am out of this nonsense here I really don't have anything
more on it to say I do find it hilarious given the scope of how
insignificant all this is, and we have never pushed our version
standard on anyone, if you don't like to use it then its fine just
don't use it.
On 25.5.2005, at 20:49, Brendan Murphy wrote:
Alfred wrote:
Brandon, I don't think I appreciate the discussion. You are mixing
plugin related issues with issues regarding ethics, politics.
Plugin versioning is important, RS has not addressed it fully,
Björn offers an alternative and you could provide something else
of course. but you need to do some work.
With all due respect, your comment doesn't make sense. Other than
mentioning the fact that Bjorn once threatened to leave the RB
plugin development, what ethics or politics issue have I
addressed? Even in that example I pointed it out to demonstrate
the "risk" of of following a closed source solution for this set
of circomstances. There are two underlying issues, (1) vendor
acceptance and (2) tool availability. For issue 1, Bjorn has built
in resistance to issuse 1 into the tool. If Bjorn doesn't feel
like updating his tool at another vendor's request, what does the
vendor do? For issue 2, if Bjorn's tool goes away, what do new
users download?
I once remember listening to a story of one of the original
authors of UML when they were formulating UML. They saw the
incompatibilities and different terminalogies of all the different
methedologies, so they decided to try to unify the methodolgies.
The guy said they knew going into the task that there was a high
risk of going in with 4 different methodogies, but in the end just
producing a 5th methodogy. The point is they wanted to relieve the
confusion between the methodogies, but they ended up just
producing just "another" methodogy. Where there was once 4, now
there are 5. By the same principle, the same thing is happening
here. One group will do it Bjorn's way and another group will
version there help folder. We are now preciecly in the position I
have been describing all along. Neither solution is accepatable in
my case for team development, so I am forced to come up with
something different.
It is faily obvious that due to a lack of interest or
unwillingeness there is no way to get a concensous an this make it
possible to effectively manage plugins on this level. It was worth
a shot. Therefore I must come up with a seperate solution for
myself that solves the problem regardless of what a vendor does to
version their plugins. So where there was once 2 ways to verion a
plugin, there will now be 3. I was was hoping to not have to do
this.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|