On 5/11/2010 10:12 AM, Richard Hipp wrote: > > The current policy is that I create new binaries whenever there is a > major bug that needs fixing, or a major new feature, or as the mood > strikes me. I think this "policy" is one of the major complaints > about Fossil. Can anyone suggest a better policy? When should I do > new builds?
How is it done with SQLite? I'd say it's fine to make builds available during non-official release times, but label them as development builds. Fossil should have a roadmap that says feature A, B and C make it 1.0. When those three features exist, it'll be 1.0. Thus, if the current fossil has feature A, it should be 0.3 or somewhere around there and it shouldn't reach 0.6 until feature B exists also. Right now no one knows if fossil is 0.0.001 or 5.8.12. Then, say it is 0.3.? when a few major bugs are fixed, push out 0.3.1, 0.3.2, etc... It adds to the development cycle of tracking and managing those numbers but I think most will think it's worth it. Jeremy _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
