Course, this seems ideal. But I'm pretty sure that already 80% of the value will come if we just correctly "control" what we deliver to newbies in terms of fixed dependency graph.
2010/6/29 Tim Daly <d...@axiom-developer.org>: > This is a well-solved problem in open source. > > It involves keep a "gold version" of the system on some well-known > site (e.g. sourceforge) and a "silver version" on another well-known > site (e.g. github). > > The gold version is released on a regular basis (say, once every 2 > months). It is tested using an ever-growing test suite. It is > packaged with both source and binary for a wide variety of systems. > There should be a website supporting the gold version. Docs on this > site are up to date. There is a revision history. > > The silver version changes daily. Changes are only posted to the > silver system after they pass the test suite. If they add new functions > they are posted with new tests. If they change old functions the tests > have to be updated to pass. It is a cardinal sin to "break the build". > A week before release to Gold the silver version is frozen except for > bug fixes. > > Laurent PETIT wrote: >> >> ... at least it's my opinion : we should stop consider newbies are as >> excited as us by the idea of working with SNAPSHOT dependencies which >> work day A, break day B. >> >> So .... I think we should have no SNAPSHOT dependencies in the Getting >> Starting docs, or transitive SNAPSHOT dependencies. >> >> We can still have snapshots, of course ! But always have the doc point >> a version known to work and whose dependencies are totally resolved. >> >> >> Shameless plug, but I think that plugins for IDEs like >> Counterclockwise for Eclipse, Enclojure for Netbeans, La Clojure for >> Intellij have less "I don't manage this up and running" messages is >> because the users are provided with pre-built and pre-tested versions. >> >> Interestingly enough, problems with Enclojure seem to arise when >> * the people try to deal with labrepl (I guess labrepl has SNAPSHOT >> dependencies) >> * the people try to install enclojure in the most recent version of >> Netbeans (but here, the people doing this eat their own food, since >> they don't use one of the versions of netbeans suggested by the >> enclojure team). >> >> In both cases, guess what ? Configuration management is the problem. >> >> HTH, >> >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
