5 Commits

Author SHA1 Message Date
Kevin Masaryk
31411b4f1a Significant amount of changes in this update. All dependencies on the 'sugar_type' table have been removed. I left the table intact in the db in case we run into bugs in this release and need it for reference. It should be dropped in the next release, though. Each feremntable table (malt, extract and adjuncts) now contains it's own PPG field so no lookups need to be done in 'sugar_type' (see below).
The lovibond fields have also been removed from each fermentable table and two new fields were added in its place: 'xxxLovibondLow' and 'xxxLovibondHigh' (see below). Only LovibondLow is a required field; If LovibondHigh isn't present, the LovibondLow value will be used as the high value. For example, if Low is 8.00 and High is 0.00 then the range will become 8.00-8.00 in all calculations and presentation of the Lovibond data.

I've also made type updates to most fields in each fermentable table to better reflect the data being stored. This should increase query efficiency, reduce db size and ensure sane data is added.

Obviously, a ton of files had to be updated to enable these changes to the db tables. I also created two new 2.3.3 files under sql/ for new installs or updates.

**Lovibond calculations are currently broken.** This is something I'm working on but I wanted to commit the code I have now since all the sugar_type and PPG changes are finished.

'malt' table
maltYield --> maltPPG
maltLovibond --> dropped
maltLovibondLow --> added
maltLovibondHigh --> added

'extract' table
extractYield --> extractPPG
extractLovibond --> dropped
extractLovibondLow --> added
extractLovibondHigh --> added

'adjuncts' table
adjunctYield --> adjunctPPG
adjunctLovibond --> dropped
adjunctLovibondLow --> added
adjunctLovibondHigh --> added
2011-06-08 22:21:29 +00:00
Kevin Masaryk
b4640b6d07 Hydrometer Calc
Rearranged some of the code for readability and easier management.
Minor update to the interface.

Bitterness Calc
Significant rewrite to much of the code.
Modified interface to allow dynamic additions of hop entry fields.
Max number of hop entry fields is controlled by a constant at
the top of the file: $MAX_HOPS.
Moved all constants to the top.
Moved all JavaScript to bitterness.js since there's a lot more of
it now - the hop entry field stuff is all JS.
Modified the interface to make Garetz calculations optional.
Modifications to $pelletFactor. This is a constant at the top
right now but will soon be set in prefs.
Moved all IBU formulas into a separate library, bitterness.lib.php.
This will allow all IBU calculations to be handled in one file
instead of duplicating the code. The next step is to convert the
recipe/blog IBU code to start using it.

Updated all relevant files to link to the two calculators which
were modified/added.
2010-07-20 17:49:32 +00:00
Geoff Humphrey
85506af498 Finalizing 2.3.2 release items. 2010-06-24 21:01:22 +00:00
Geoff Humphrey
73e158028f Preliminary 2.3.2 commits. Updated navigation schemas and bug fixes. New theme. 2010-02-05 18:37:27 +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