Code freeze...
Hi team, please avoid making commits right now. I'm going to do a RC for 5.1.1 now. Glen
Re: code freeze...
oops sorry, made a commit. On 20 August 2014 17:42, Glen Mazza glen.ma...@gmail.com wrote: If people could refrain from svn commits today, I'm making the 1st rc right now. Thanks, Glen
Re: code freeze...
Commits are OK, per my [VOTE] email, as I'm not making another RC just yet. Just be very cautious/conservative in commits as they go into 5.1, major stuff can wait until after we release. I'll be freezing again soon for RC3. Thanks, Glen On 08/21/2014 05:40 AM, Greg Huber wrote: oops sorry, made a commit. On 20 August 2014 17:42, Glen Mazzaglen.ma...@gmail.com wrote: If people could refrain from svn commits today, I'm making the 1st rc right now. Thanks, Glen
[FAILED][CODE FREEZE: On]Re: [VOTE] Release Apache Roller 5.1
On 08/21/2014 05:39 AM, Greg Huber wrote: Glen, On upgrading/testing. ## One of my databases failed on this statement on the upgrade. The index did not exist. ALTER TABLE bookmark_folder DROP INDEX folder_namefolderid_uq; Its does mention it may not exist. Hi Greg, yes, I put a change in the code for dropping of nonexistent indexes to be a non-fatal upgrade error, seeing that we don't need to fail if we're trying to delete something that already doesn't exist. Some roller installs have indexes that others don't, and I just want the upgrade to proceed in those cases, rather than leave people with a half-completed database. http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/business/startup/SQLScriptRunner.java?r1=1580425r2=1613234diff_format=h ## Formatting section on preference | settings Not sure on this now, maybe needs to be removed from WeblogConfig.jsp as bean.defaultPluginsArray has been removed. s:if test=!pluginsList.isEmpty tr td class=labels:text name=websiteSettings.label1 / br /s:text name=websiteSettings.label2 //td td class=field s:checkboxlist theme=roller list=pluginsList name=bean.defaultPluginsArray listKey=name listValue=name / /td td class=description%-- s:text name=websiteSettings.tip. / --%/td /tr /s:if s:else s:hidden name=defaultPlugins / /s:else My error, I should not have removed defaultPlugins from the Weblog class, in my email of July 23rd I recommended its removal without realizing it was indeed configurable at the blog level: 8.) defaultplugins: Always null, no place to configure at the blog-level, as with #2 above, perhaps best to let the blog admin configure this for all bloggers in the roller-custom.properties file. I'll put this back in and come up with another RC3 today. Regards, Glen
Re: [FAILED][CODE FREEZE: On]Re: [VOTE] Release Apache Roller 5.1
On Thu, Aug 21, 2014 at 12:42 PM, Glen Mazza glen.ma...@gmail.com wrote: On 08/21/2014 05:39 AM, Greg Huber wrote: Glen, On upgrading/testing. ## One of my databases failed on this statement on the upgrade. The index did not exist. ALTER TABLE bookmark_folder DROP INDEX folder_namefolderid_uq; Its does mention it may not exist. Hi Greg, yes, I put a change in the code for dropping of nonexistent indexes to be a non-fatal upgrade error, seeing that we don't need to fail if we're trying to delete something that already doesn't exist. Some roller installs have indexes that others don't, and I just want the upgrade to proceed in those cases, rather than leave people with a half-completed database. http://svn.apache.org/viewvc/roller/trunk/app/src/main/ java/org/apache/roller/weblogger/business/startup/SQLScriptRunner.java?r1= 1580425r2=1613234diff_format=h The problem with that fix is that many sys admins prefer (that was my first inclination and Greg's too) to run the database script manually instead of letting Roller run the script. When you run the script manually, that error causes the script to fail. Possible solutions: * In the upgrade docs, tell people not to run the script manually * In the upgrade docs, tell people that want to run manually they should use a continue on error appropriate for their database (on MySQL this is the --force option) * Provide a command line program that does runs the migration and ignores errors - Dave
Re: [FAILED][CODE FREEZE: On]Re: [VOTE] Release Apache Roller 5.1
On 08/21/2014 02:08 PM, Dave wrote: On Thu, Aug 21, 2014 at 12:42 PM, Glen Mazzaglen.ma...@gmail.com wrote: On 08/21/2014 05:39 AM, Greg Huber wrote: Glen, On upgrading/testing. ## One of my databases failed on this statement on the upgrade. The index did not exist. ALTER TABLE bookmark_folder DROP INDEX folder_namefolderid_uq; Its does mention it may not exist. Hi Greg, yes, I put a change in the code for dropping of nonexistent indexes to be a non-fatal upgrade error, seeing that we don't need to fail if we're trying to delete something that already doesn't exist. Some roller installs have indexes that others don't, and I just want the upgrade to proceed in those cases, rather than leave people with a half-completed database. http://svn.apache.org/viewvc/roller/trunk/app/src/main/ java/org/apache/roller/weblogger/business/startup/SQLScriptRunner.java?r1= 1580425r2=1613234diff_format=h The problem with that fix is that many sys admins prefer (that was my first inclination and Greg's too) to run the database script manually instead of letting Roller run the script. When you run the script manually, that error causes the script to fail. OK, I just saw the relevant section in our Install Guide (Section 10.2), to me manual process meant the DBA ran the statements one-by-one before going on to the next, not that they would run a single SQL script without looking at or modifying its contents, as the latter process wouldn't give them much advantage over the automated process. We've already commented in the migration script that this index may not exist and hence manual upgraders may not wish to run the statement: -- If you run this script manually (i.e. you are doing installation.type=manual) -- them you may need to comment out this next statement, this index does not -- exist in all Roller systems: alter table bookmark_folder drop index folder_namefolderid_uq; Possible solutions: * In the upgrade docs, tell people not to run the script manually That's too strong. I just need to update the section saying that the migration script may not be runnable as a whole as some databases throw an error when one attempts to delete an index or foreign key that does not already exist, something that the automated process takes care of automatically. Therefore, manual upgraders may need to run the upgrade statements one-by-one rather than the script as a whole, or comment out drop index or foreign key statements that they already know don't exist. I'll get that done. * In the upgrade docs, tell people that want to run manually they should use a continue on error appropriate for their database (on MySQL this is the --force option) Possible, but continue on error is too dangerous because you need to know what the error is. Dropping something that doesn't already exist is normally survivable, but other types of errors you do want the database script to halt on. Manual updaters, i.e., those leery of relying on our automated process, would probably also be equally leery of continue on error. Glen
code freeze...
If people could refrain from svn commits today, I'm making the 1st rc right now. Thanks, Glen
