"Alexander Kitaev" <email@example.com> wrote on 08/25/2005 05:15:51 PM:
> > automatically. This way you can share library between plugins
> > and also update their versions independently...
> I fully agree with you and would vote for this approach. As soon as Mark
> me will have more time, I hope it will be possible to make JavaSVN
> as a separate plugin.
I actually do not think it is clear which approach is best, and since it
would take a fair amount of work to implement your suggestion, the easiest
thing to do would seem to be to go with what we have now and see how it
works out. I would not anticipate having any problems putting out new
releases when your new releases are available, and there might be some
benefit to letting us test your official release for a few days before
releasing it to everyone anyway.
My main concern is one of confusion. I really want to include JavaSVN (in
whatever form) in a default install of Subclipse. I think it then
potentially becomes confusing for someone to get the updates from multiple
places. So unless it becomes a problem, I think we should try just
packaging it with Subclipse. It is also conceivable that at some point in
time you might have two or more lines of development active, such as one
that is tracking a current Subversion release, and one that is fixing an
older release. Such as when Subversion goes to 2.x. In that scenario,
there might also be two lines of Subclipse active. It would be easier to
keep the compatible versions together if it all comes with Subclipse. I
realize this is a pretty contrived example, but my main point is that I do
not see any need to rush into any changes here.
I would just suggest that if you find some critical bug in JavaSVN that is
going to cause you to put out a new release you just let us know so that
we can get it out to users as soon as possible as well.
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
Received on Fri Aug 26 11:00:10 2005