Re: API-changing releases

On Fri, Jan 09, 2004 at 11:57:18AM -0500, Greg Hudson wrote:
> On Fri, 2004-01-09 at 00:44, kfogel@collab.net wrote:
> > So why are we trapping ourselves into this?
>
> If we expect our API to be successful, then we should expect that when
> we make an incompatible API change, it will take a while--possibly
> months or years--before all interesting third-party programs are updated
> to use the new API. gnucash still hasn't finished porting to GNOME 2.

Agreed.

> Therefore, when we make an API-breaking release, we need to paint a
> bright red flag on it which tells people not to upgrade by replacing the
> old version of svn, but instead to co-locate the new version with the
> old version.

Agreed, and I'll note that the versioning guidelines are defined in such a
way as to *enable* colocation of the libraries. There can only be one
command line, but the libraries and include headers can sit right next to
each other without problems. (IOW, the stuff that third-party apps need)

> With your scheme, there is no such bright red flag; not only would the
> initial version number not change, but a middle version number change
> *might or might not* signal an incompatible API change.

Yup.

And note that going from 1.x to 2.x implies a serious API breakage. I
can't see us doing that in the next year. Adding APIs? Sure. But breaking
existing ones... no.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org