Right. We could just have a branch called "classic" on github. Leaving everything untouched.
And then change the gem name to camping-classic or something. Maybe we should rewrite it afterwards (kind of). And make it backwards compatible with Camping applications. Just make the infrastructure simple and minimalistic. And make it easy to extend and configure. I think this would be the best thing ever for Camping more or less. Cheers! Isak Andersson Philippe Monnet <r...@monnet-usa.com> skrev: On one hand everyone is free to fork anything to change radical direction. This would allow for the size and some design constraints to be eliminated. But on the other hand, at this point in time (since we are the new community) shouldn't we free ourselves from the original constraints and just ignore the size aspect? I personally think so. It does not mean we have to "go crazy" and make it large and complicated (like Rails). With the source being on Github, we can just designate the current version as the "classic" (super micro version) and document very explicitly that from now on we will be free of these constraints and explain how people can still get the "classic" version. Since the framework has proven extremely stable and resilient, this would not prevent any tinkerer who needs the classic version to just do so. Although it has been fun to reference the size when talking about Camping, keeping it reasonably simple and small is good enough for me. "... free free set them free ..." On 4/13/2012 9:55 AM, Isak Andersson wrote: I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt <dever...@innotts.co.uk> skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. Get the best selection of online sites here. Click Here to check them out! http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ _______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Play Your Favorite Free Games Right On Your Browser - 100% Free! http://click.lavabit.com/d663gxud89959x7mk3m3o7u8hp6r8h6yfbx1dkxash7qztba1ify/
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
