As long as the upgrade path is intuitive, I don't see a reason not to require version 1.2 in
future releases. I agree that tags of previous versions should be maintained so bug-fix releases
could be made, but in general the benefits of upgrading seem to outweigh the costs.
> I propose that we do the following repository restructuring as part of
> this:
>
> 1) Create branch for "eclipse2.x" and populate with that version of
> Subclipse and also the version of svnClientAdapter used at that time.
>
> 2) Delete the Subclipse stuff from trunk.
>
> 3) Copy the Subclipse stuff from subclipse-3 branch to trunk. This is
> where "normal development" will take place.
>
> 4) Copy svnClientAdapter to subclipse-3 branch so that we can still
> easily do fixes for the svn 1.1 version if necessary.
>
> This would get us in better position to support the various versions as
> well as make it easier for future users to get the right source. I think
> a key element of this would be including the correct svnClientAdapter in
> the various branches.
>
> Finally, while these changes are directly related to the 1.2 issue, I
> would still look for ways to have one version of Subclipse support both
> versions of Subversion. I just do not think it is going to be possible,
>
> Thanks
>
> Mark
>
> _____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by
> MessageLabs.
> _____________________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: dev-help@subclipse.tigris.org
>
>
Received on Wed Apr 13 03:56:40 2005