Fork me on GitHub
Subscribe 6

Ticket #390 (open enhancement)

Create new update script

  • Created: 2011-04-08 11:05:18
  • Reported by: Franz
  • Assigned to: Franz
  • Milestone: 2.0-beta1
  • Component: upgrading
  • Priority: highest

2.0 will allow for upgrading from 1.4.*. The same should be true for all pre-2.0 development versions, as there will be schema changes now or later.

That means we definitely need to create a new upgrade script.

Maybe it's actually going to be a clean, non-messy one, with proper support for usage from shell and automatic maintenance mode wink

History

Reines 2011-04-11 23:52:12

Changes so far:

  • add sessions table

  • remove online table

  • change password and activate_string lengths in users table

Also the upgrade script must convert non-empty salt columns into $13$saltpassword in the password column in-case converting from a board which has been upgraded from 1.3.

Reines 2011-04-12 09:42:09

I was thinking of splitting the update script up a bit, and having:

  1. A converter that will convert from FluxBB 1.4, and potentially any other versions or forum software we wish, to FluxBB 2.0.0. This would be a separate package (i.e. fluxbb/converter), and could include extensions which would handle password conversion etc. It would be created as part of the final milestone (alpha6/beta1/whatever).

  2. An upgrade script which would handle converting between FluxBB 2.0.0 -> FluxBB 2.0.1, for example.

  3. A temporary script which we can use during development to keep our databases in sync.

2 and 3 would differ in that with 2 we could use the version numbers to tell us exactly what to change, instead of checking the existing structure, which should be safer, tidier, and more efficient. During development though we don't necessarily want to keep version numbers (and there's no need for the final release to include development stuff), so a separate more hacky script should be fine.

Reines 2011-04-18 10:35:52

  • Owner set to Reines.

Franz 2011-11-02 12:07:23

What about the old idea of integrating the converter into the install script? (Plus also adding a package for FluxBB 1.4 as a "conversion" rather than an update.)

daris 2011-11-25 19:56:00

Another change that update script have to do - move base_url from database to config.php
http://fluxbb.org/development/core/tickets/543/

Studio384 2012-05-03 20:12:43

Is it still necessary to give the database password if you want to update FluxBB?

Franz 2012-05-03 22:04:47

I think it will be - why not?

arw 2012-05-03 22:08:35

?

well if there is a change in database ( and a password is needed to access it ), the update script would need the password to upgrade the database  ( but well if you upgrade the forum your forum has probably access to database ( or it would not be very usable ) so the update script can just use the forum config )

Franz 2012-05-03 22:12:16

No, that option was actually introduced so that only admins could run the upgrade script.

arw 2012-05-03 22:27:32

ok, i upgrated some days ago to 1.5 but with sqlite no password ( have to put the name of database ) so i forgot

Franz 2012-05-23 21:54:33

More things to update:

  • change language names to codes (#595)

Studio384 2012-06-29 19:43:34

@Franz, well, that you just have to run the update, why asking for a password? If there is already a connection?

arw 2012-06-29 19:51:29

so that only admins could run the upgrade script

Franz 2012-07-07 19:40:45

  • Owner changed from Reines to Franz.

AlexCogn 2012-07-08 23:36:29

Try not to forget that there will also be installations as bundle for those who already own a laravel website. Maybe an option within the installation for your database where you select if you do a stand-alone install or as bundle.

Franz 2012-07-11 14:27:44

And another thing to handle:
users' password column should be 60 characters long.

Franz 2012-07-11 15:13:25

Commit 3e5bcb1 to core master

For #694 and because of #702, users' passwords are now 60 characters long (we make use of Laravel's hashing functionality).

Affects #390.

Franz 2012-08-25 20:59:20

Commit 3800c98 to core master

#390: Add console "task" for updating to a specific version.

Franz 2012-08-25 22:41:52

Commit c7370c2 to core master

As examples, add two migrations 1.4.9 -> 1.5.0.

Related to #390.

Franz 2012-08-27 12:55:11

Commit 6da8fbf to core master

#390: Add migration for removing ranks table in 1.5.0.

Franz 2012-08-27 12:55:53

Commit e055167 to core master

#390: Small migration for removing the moderators column from the forums table.

Franz 2012-08-27 13:29:56

Commit 9bf8567 to core master

#390: Add migration for removing online table in 2.0.

Franz 2012-08-27 13:31:29

Commit fab7542 to core master

#390: Add two more methods to upgrade script for running single migrations in the current version.

Franz 2012-08-27 14:05:42

Commit 3f75f65 to core master

#390: Add migration for removing old search tables in 2.0.

Franz 2012-08-27 14:15:59

Remaining migrations in alpha1:

  • updating language column for users (keys instead of full language)

  • removing old, unneeded config keys (base URL)

  • user's password column needs to have length 60

The last one is tricky as Laravel doesn't really support altering columns.

Franz 2012-08-31 20:19:46

Commit cc7a39b to core master

#390: Implement combined migration for introducing sessions table instead of online table in 2.0.

Franz 2012-09-19 12:35:54

  • Milestone changed from 2.0-alpha1 to 2.0-beta1.

I'll move this back.

The way I see it: we'll use standard Laravel migrations during development of 2.0.

Once final, we'll build a pretty upgrade script for the 2.x releases. Upgrading from old versions, like the 1.x era, will be handled in the installer (extra "Import" option).