> On Mon, Jul 31, 2006, Bob Copeland wrote: > > > We could either release new versions of lkarmafs and libkarma now and > > > fix that afterwards or delay the release of both until after this is > > > fixed. > > > > My preference would be that 0.0.5 be released sooner rather than later > > (with the no-ops above) and save any API changes for the next version. > > Agreed. > > > We should probably rev it to 0.1.0 for that second release. > > Actually, the lkarmafs fix only needs *additions* to the API rather > than changes. I should have been clearer on that point. > So that shouldn't require a major revision increment.
I understand; however 0.1.0 isn't a major revision increment, though. 1.0.0 would be. The usual way for handling things in libraries is to increment the minor revision that adds new functionality but doesn't break any old, and increment the major version when making fundamental API changes. Then keep the soname in sync with this. Of course, libkarma has few users and is still pretty beta, so 1.0 might well be infinitely far away, so we don't have to follow this scheme yet. -- Bob Copeland %% www.bobcopeland.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-karma-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-karma-devel
