Sorry about this. Place the attached file in core/lists/.
I cannot be 100% sure that it works without problems (it handles session memory for lists, searching, etc.) but I have tested it on a 6.7.2 server and run various tests without problem. I believe it is the file that fixes the #636 bug.
Great to hear! We did promise ourselves that we would be quicker to make releases but one thing leads to another and we're now about 6 months on since the last release. Your post is a reminder to keep to the straight and narrow!
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the planned developments I fear the releases will take longer than 3-6 months even with good will. There are some features that are just too big or you really need to think about incremental development that breaks the features into chunks.
For us this consists of reserving the increment of the number Z of the version number X.Y.Z and reorganizing the repository to use branches.
The branches would be a way to apply error and security corrections to the a previous release, not a way to develop, to avoid the problems we had before.
There is still a difficulty because the release programs depend on the code of WIKINDX, the version of PHP, ... I cannot go back beyond 6.5.0 for the generation of the manual.
So we need to define a release policy. For example, commit to patching the last N releases, including security fixes or not. The more you add, the heavier it is.
The structure of the repository would become (there is still a problem of interdependence between the release programs and the current WIKINDX code):
trunk
extras
release
test
third_party
tools
wikindx
website
X1.Y1
extras
release
test
third_party
tools
wikindx
website
X2.Y2
extras
release
test
third_party
tools
wikindx
website
...
Regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't a clue about all this Stéphane so I am happy to take your advice. I was thinking this morning about branches as a means to separate security fixes and similar and large-scale feature development.
But perhaps a discussion of this in another thread? So we can at least find it again.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, I begin to regret to have started this discussion. I'm happy with the patch, no need to hasten or to complicate the development process! Take your time!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No worries Joachim . . . it's a discussion Stéphane and I have been having for some time and are actually in agreement on. The problem is we either underestimate how long something will take or we (i.e., me) succumb to the temptation to do just one more improvement. . . . So, your plea was a useful reminder to be strict with ourselves. . . .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mark and Stéphane,
help, my uni is threatening to shut down my server if I won't fix the SQL inject bug I reported as #636. Could you please send me a fix for v6.7.2?
Best
Joachim
Hi Joachim,
Sorry about this. Place the attached file in core/lists/.
I cannot be 100% sure that it works without problems (it handles session memory for lists, searching, etc.) but I have tested it on a 6.7.2 server and run various tests without problem. I believe it is the file that fixes the #636 bug.
Regards,
Mark
Thank you, Mark, looks good so far!
Great to hear! We did promise ourselves that we would be quicker to make releases but one thing leads to another and we're now about 6 months on since the last release. Your post is a reminder to keep to the straight and narrow!
Mark
Hi Mark,
With the planned developments I fear the releases will take longer than 3-6 months even with good will. There are some features that are just too big or you really need to think about incremental development that breaks the features into chunks.
We follow Trunk Bases Developement. To answer the problem of the day there is the Branch for release technique, which we have not yet implemented.
For us this consists of reserving the increment of the number Z of the version number X.Y.Z and reorganizing the repository to use branches.
The branches would be a way to apply error and security corrections to the a previous release, not a way to develop, to avoid the problems we had before.
There is still a difficulty because the release programs depend on the code of WIKINDX, the version of PHP, ... I cannot go back beyond 6.5.0 for the generation of the manual.
So we need to define a release policy. For example, commit to patching the last N releases, including security fixes or not. The more you add, the heavier it is.
The structure of the repository would become (there is still a problem of interdependence between the release programs and the current WIKINDX code):
Regards,
I haven't a clue about all this Stéphane so I am happy to take your advice. I was thinking this morning about branches as a means to separate security fixes and similar and large-scale feature development.
But perhaps a discussion of this in another thread? So we can at least find it again.
Mark
Ok, I moved the discussion to [327c9c8e10].
Related
Discussion: 327c9c8e10
Noted . . .
Oops, I begin to regret to have started this discussion. I'm happy with the patch, no need to hasten or to complicate the development process! Take your time!
No worries Joachim . . . it's a discussion Stéphane and I have been having for some time and are actually in agreement on. The problem is we either underestimate how long something will take or we (i.e., me) succumb to the temptation to do just one more improvement. . . . So, your plea was a useful reminder to be strict with ourselves. . . .