brewblogger

salfter/brewblogger

Fork 0

Commit Graph

Author	SHA1	Message	Date
George Hotelling	5d6bdd07aa	Stabilizing trunk so that development can continue. * Removed check_mobile include which was crashing pages like the admin section (it was previously added to functions.inc.php) * Fixed ABV display in lists * Fixed bitterness calculations. * Removed call-time pass-by-reference in BeerXML parser, since it is no longer supported by PHP	2012-08-11 15:08:49 +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
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

Author

SHA1

Message

Date

George Hotelling

5d6bdd07aa

Stabilizing trunk so that development can continue.

* Removed check_mobile include which was crashing pages like the admin section (it was previously added to functions.inc.php)
* Fixed ABV display in lists
* Fixed bitterness calculations.
* Removed call-time pass-by-reference in BeerXML parser, since it is no longer supported by PHP

2012-08-11 15:08:49 +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

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

3 Commits