0.9.6 final sanity checks, please help

I don’t want to release another RC, so if everyone on the testing team that has a few minutes today could do a quick new install and/or upgrade using revision 2754 of trunk (yes this is a "candidate" for final 0.9.6 release) and report any show-stopping bugs for release ASAP. Non-critical issues should be reported in the bug tracker.

Here are zip and tar.gz downloads of the build...

http://modxcms.com/testbuilds/modx-0.9.6-2754.zip
http://modxcms.com/testbuilds/modx-0.9.6-2754.tar.gz


BTW, my goal is to streamline our development processes following this 0.9.6 final release, so that we can start releasing much more often (I’d like to see at least one minor release per month). This may increase some short-term support loads on specific issues in each release, but I believe in the long-run, these more frequent releases will reduce our overall support burdens by getting bug-fixes out the door faster.

Hi,

I’ve given a fast test and this QE bug is still there => http://modxcms.com/bugs/task/818
(QuickEdit doesn’t store all data of Multi-Select Checkbox TV to DB)


:-)

Quote from: heliotrope at May 22, 2007, 01:27 PM

I’ve given a fast test and this QE bug is still there => http://modxcms.com/bugs/task/818
(QuickEdit doesn’t store all data of Multi-Select Checkbox TV to DB)

That one’s marked Low priority, and will not make it into the 0.9.6 release. I’m focused only on MODx core issues that are of critical severity to get this out the door ASAP; it’s long overdue. If someone wants to take a look at that ticket, feel free to submit a patch so it gets into QE repository releases and minor/patch releases of the 0.9.6 branch...

I found this "bug" a while ago but wanted to test it...

In the [tt]checkPublishStatus()[/tt] function when documents are to be updated with a new [tt]publishedon[/tt] timestamp, I found that in the query, ALL of the documents with a valid [tt]pub_date[/tt] field would be updated with a new timestamp. This is undesired, as the [tt]publishedon[/tt] timestamp will not show the real time in which it was published, it would simply reflect the last Publish Status run.

I consider this a bug and have fixed it in [tt]branches/0.9.6/ @ 2755[/tt].

Quote from: sirlancelot at May 22, 2007, 06:57 PM

I found this "bug" a while ago but wanted to test it...

In the [tt]checkPublishStatus()[/tt] function when documents are to be updated with a new [tt]publishedon[/tt] timestamp, I found that in the query, ALL of the documents with a valid [tt]pub_date[/tt] field would be updated with a new timestamp. This is undesired, as the [tt]publishedon[/tt] timestamp will not show the real time in which it was published, it would simply reflect the last Publish Status run.

I consider this a bug and have fixed it in [tt]branches/0.9.6/ @ 2755[/tt].

Good catch, and I would consider that close to critical, so I’ll merge it in. For consistency’s sake, can you please enter a bug report in the tracker and indicate it is ready for testing? I’m considering making it a requirement to submit an appropriate Flyspray entry for any commits that are to be merged into trunk, regardless if it’s a quick bug fix, a usability improvement, or a brand new feature.

Quote from: OpenGeek at May 22, 2007, 08:38 PM

For consistency’s sake, can you please enter a bug report in the tracker and indicate it is ready for testing? I’m considering making it a requirement to submit an appropriate Flyspray entry for any commits that are to be merged into trunk, regardless if it’s a quick bug fix, a usability improvement, or a brand new feature.

Be happy to!

I agree that it should be a requirement for all bugs/fixes except the most minor, such as spelling errors in text (unless its a spelling error in the code). Flyspray is a great way to collaborate. If only it were possible to set up SVN to talk to Flyspray somehow...

http://modxcms.com/bugs/task/871

Enjoy!

I may have found a small typo in the installer (minimal):

Ditto - 2.0.2 Summarizes and lists pages to create blogs, catalogs, PR archives, bio listings and more.

I thought the most recent SVN came with Ditto 2.0.3 per the SVN logs...either I am mistaken, or the installer needs to reference the correct version.

So to sirlancelot’s point, should spelling errors also require Flyspry interaction??

2.0.3 was backed out at Mark’s request due to a bug in the parser. No flyspray for spelling corrections corrected, flyspray for bugs for sure, even if accompanied by correction commits.

Quote from: pixelchutes at May 22, 2007, 11:22 PM

So to sirlancelot’s point, should spelling errors also require Flyspry interaction??

No, fixes as small as spelling errors aren’t neccessary. I’m talking about language string spelling errors. Coding spelling errors (such as "functon" instead of "function") would be a toss up as to whether or not they need a FS ticket.

Flyspray should be a tool to help us (the coders), not be a burden that we have to report to.

Just thought it’d be good to report that I updated my current test site from 0.9.6 RC2 to this revision with no problems at all so far (regular update; installed all extras except for the default content and QuickEdit).