Commit Graph

4 Commits

Author SHA1 Message Date
George Hotelling
9da2f4ec9f Adds iCalendar file for upcoming brewBlogs and the upcoming recipes. It can be accessed from a link in the upper-right of the calendar screen, and should work both with single-player and massively multiplayer sites.
Note that this adds a new 3rd-party library, iCalcreator.class.php from http://kigkonsult.se/iCalcreator/index.php (GPL/LGPL dual licensed)
2012-08-13 02:38:42 +00:00
Geoff Humphrey
6de47e4da0 Beginning consolidation effort. The plan is to house all functions in the functions.inc.php file, streamline db calls by "modules" to call when needed and not on every page load (hence the addition of the 'db' sub-directory in the 'includes' directory. Also, beginning to eliminate unneeded tables in favor of CSS for presentation purposes. The recipe_specifics.inc.php file reflects the newer presentation schema. 2011-09-04 18:35:17 +00:00
Geoff Humphrey
d32b264710 First 2.3.3 commits. 2010-03-22 22:24:31 +00:00
visual77
89b9b4f575 Restructured the repository to follow the more traditional SVN structure.
The trunk folder is for all new features that are not yet ready for release. This folder will be for stabilizing work as it is built and creating new features.

The releases folder is used for release builds. The earliest available build is 2.3.x, and thus it will have the 2.3 folder. All maintenance and bug fixes go in this folder. No new features whatsoever are to be added in here, keeping those completely in the trunk. When the trunk is ready for the next version, it will have a new folder created for it (releases/2.4 for instance) to stabilizing for final release.

The tags folder is used for individual releases. When a release build is ready to go out for download, that release folder will be cloned into an appropriate tag folder. For example, the releases/2.3 folder will be cloned into tags/2.3.1 for that release, and after more work on bug fixes, it will be cloned to tags/2.3.2. Thus, these tag folders should never be modified for any reason. The tag exists purely as a snapshot of a certain point on the release path, and to modify a snapshot defeats the purpose. Any bug in a tagged release should be fixed in the appropriate release folder (such as releases/2.3 for a bug found in 2.3.1).
2009-10-16 22:09:45 +00:00