This is a draft only, please extend and correct if you are sure about what you are doing!
The patches strategy for 3.4.0 doesn't involve migration scripts.
The patches strategy for 3.5.2 DOES involve migration scripts compiled weekly.
So, when you install a patches for 3.4 - that can be installed directly without running any migration script.
Now, for 3.5.2a
- you install from Adempiere_352a.tar.gz (this is corresponding to tags/adempiere352a - at this moment (fresh installation of 352a) you have a database 352a (july 30)
- then suppose at aug-22 you decide to install the 20080822_patches_352_6206.jar
you need to apply all the patches released until 20080822:
and then install the patches for that date.
- now suppose today you decide to install the 20080918_patches_352_6483.jar
you need to apply all the UNAPPLIED patches until 20080918, this is:
and so on, the idea is every week you apply the scripts and the jar. You need to keep control of the migration scripts applied in your database. The "weekly" scripts are just a compilation of the scripts released in stable between those dates.
Please take account that 352a is declared unstable (alpha in fact), it's possible a weekly jar break the system. I try to do the best to at least test the installation, but I can't guarantee the functionality to be stable, because those jars are based on the currently-fast-moving stable branch. For production installations you better test before in a testing environment.
For 340s the strategy is different - until now we haven't released a patch that needs a migration script to be applied. And 340s patches have normally more stability testings in real-live installations.
Same disclaimer apply here, still there's no guarantee that a patch doesn't break a 340 installation - so testing before in a testing environment is suggested. But, this is the more widely used version, so fixing bugs there will have maybe quicker response.
Created: Gabriel 13:33, 24 September 2008 (EDT)