Comments for David Mudrak's blog http://blog.mudrak.name Moodle, Mahara and beer fan Thu, 12 Jan 2012 19:40:17 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on Contributed plugins versioning by Mike Churchward http://blog.mudrak.name/2012/01/contributed-plugins-versioning/comment-page-1/#comment-2458 Mike Churchward Thu, 12 Jan 2012 19:40:17 +0000 http://blog.mudrak.name/?p=419#comment-2458 David - We are struggling with exactly the same issue, and pretty much concluded the exact same strategy. The downside is having to maintain multiple branches of exactly the same code, where only the version.php file is different. So, for example, the questionnaire plugin has MOODLE_20_STABLE, MOODLE_21_STABLE and MOODLE_22_STABLE, but there is no difference in functional code. In the Plugins database on moodle.org, I have to either add three downloads, or one for the three versions. If I go with one, then the "requires" part of the version file needs to be the oldest version of Moodle it supports. But, I think we have concludes, as you have, that the extra maintenance of three identical versions is still worth it to avoid confusion. mike David -

We are struggling with exactly the same issue, and pretty much concluded the exact same strategy.
The downside is having to maintain multiple branches of exactly the same code, where only the version.php file is different.
So, for example, the questionnaire plugin has MOODLE_20_STABLE, MOODLE_21_STABLE and MOODLE_22_STABLE, but there is no difference in functional code. In the Plugins database on moodle.org, I have to either add three downloads, or one for the three versions. If I go with one, then the “requires” part of the version file needs to be the oldest version of Moodle it supports.
But, I think we have concludes, as you have, that the extra maintenance of three identical versions is still worth it to avoid confusion.

mike

]]> Comment on Contributed plugins versioning by David http://blog.mudrak.name/2012/01/contributed-plugins-versioning/comment-page-1/#comment-2443 David Sun, 08 Jan 2012 19:27:30 +0000 http://blog.mudrak.name/?p=419#comment-2443 Thanks Edmund for your comment. Yes, I can see your point. However, I personally gave up on this level of granularity for my contributed plugins. While it is crucial to distinguish major/minor changes for things like some software's core libraries as there are dependencies on the provided API etc, my plugins are the leaves of the dependency tree. There are no other plugins relying on them. Even trying to maintain a "stable" and "development" branches for these small components used to look too much as an overkill to me. So I simply gave up and have a single sequence of the software updates. That is, the example version in the blog "2.1.3" can be read as "2.1-3" in the Drupal speech. Given that I reserve the right to append new features on older branches, sure. I agree that is suboptimal and other contributors might prefer more robust solutions. Thanks for your example provided. Thanks Edmund for your comment. Yes, I can see your point. However, I personally gave up on this level of granularity for my contributed plugins. While it is crucial to distinguish major/minor changes for things like some software’s core libraries as there are dependencies on the provided API etc, my plugins are the leaves of the dependency tree. There are no other plugins relying on them. Even trying to maintain a “stable” and “development” branches for these small components used to look too much as an overkill to me. So I simply gave up and have a single sequence of the software updates. That is, the example version in the blog “2.1.3″ can be read as “2.1-3″ in the Drupal speech. Given that I reserve the right to append new features on older branches, sure.

I agree that is suboptimal and other contributors might prefer more robust solutions. Thanks for your example provided.

]]> Comment on Contributed plugins versioning by Edmund Edgar http://blog.mudrak.name/2012/01/contributed-plugins-versioning/comment-page-1/#comment-2441 Edmund Edgar Sat, 07 Jan 2012 04:06:24 +0000 http://blog.mudrak.name/?p=419#comment-2441 This looks good if: 1) You only release new features every 6 months, in line with the new Moodle releases. 2) When you release a new feature, you don't want to make it available for older versions of Moodle, even if it would run on them perfectly well. If those things don't hold, something odd is going to happen. The fundamental problem is that since you've given up the major version version slots to the Moodle numbering, you're only left with a point release to show what features you've got. For example: I've made my first release for Moodle 2.0. mymodule 2.0.0 Bug fix: mymodle 2.0.1 I make a new feature for my module. What do I call it? Calling it: mymodule 2.0.2 ...would violate the Principle of Least Astonishment, because the normal convention is that a new feature produces a new minor version number, and risk an admin upgrading expecting security and bug fixes, and ending up confusing users with functionality changes. But I can't do: mymodule 2.1.0 ...because Moodle 2.1 isn't out yet. So I'm going to have to wait to release my software because I don't have a way to number it, which is a bit mad. But say I do. I wait 6 months and Moodle 2.1 comes out. mymodule 2.1.0. Huzzah. I can release the functionality somebody contributed 5 months ago. But people who only want to upgrade my module without upgrading their whole Moodle are going to be SOL. And there are probably quite a few people like that, because they're waiting for some other module they rely on to get upgraded too. I suppose I could ignore the normal convention and put new functionality into the point release. 2.0.2 Then Moodle 2.1 comes out and I do: 2.1.0 But 2.0.2 and 2.1.0 are the same thing. WTF? And it gets worse every 6 months - in 3 years I'll have 6 different version numbers, all pointing at the same thing. I think the right thing to do here is to look at a system that's managed to make a really modular system work properly and copy them. The obvious one is Drupal, who do things like this: 6.x-3.10 6 tells you that it works on major version 6 of Drupal. x tells you that it works on any minor version of Drupal. If it only worked on Drupal 6.2, it would be called 6.2-3.10. 3 is the major version of the module, which tells you about functionality changes. 10 is the point release of the module, which is separate from the major version so you can be confident that you can upgrade to get bug fixes and security patches without shocking your users. This looks good if:
1) You only release new features every 6 months, in line with the new Moodle releases.
2) When you release a new feature, you don’t want to make it available for older versions of Moodle, even if it would run on them perfectly well.

If those things don’t hold, something odd is going to happen. The fundamental problem is that since you’ve given up the major version version slots to the Moodle numbering, you’re only left with a point release to show what features you’ve got.

For example:

I’ve made my first release for Moodle 2.0.
mymodule 2.0.0

Bug fix:
mymodle 2.0.1

I make a new feature for my module. What do I call it? Calling it:
mymodule 2.0.2
…would violate the Principle of Least Astonishment, because the normal convention is that a new feature produces a new minor version number, and risk an admin upgrading expecting security and bug fixes, and ending up confusing users with functionality changes.
But I can’t do:
mymodule 2.1.0
…because Moodle 2.1 isn’t out yet.

So I’m going to have to wait to release my software because I don’t have a way to number it, which is a bit mad. But say I do. I wait 6 months and Moodle 2.1 comes out.
mymodule 2.1.0.
Huzzah. I can release the functionality somebody contributed 5 months ago.
But people who only want to upgrade my module without upgrading their whole Moodle are going to be SOL. And there are probably quite a few people like that, because they’re waiting for some other module they rely on to get upgraded too.

I suppose I could ignore the normal convention and put new functionality into the point release.
2.0.2

Then Moodle 2.1 comes out and I do:
2.1.0

But 2.0.2 and 2.1.0 are the same thing. WTF? And it gets worse every 6 months – in 3 years I’ll have 6 different version numbers, all pointing at the same thing.

I think the right thing to do here is to look at a system that’s managed to make a really modular system work properly and copy them. The obvious one is Drupal, who do things like this:
6.x-3.10

6 tells you that it works on major version 6 of Drupal.
x tells you that it works on any minor version of Drupal. If it only worked on Drupal 6.2, it would be called 6.2-3.10.
3 is the major version of the module, which tells you about functionality changes.
10 is the point release of the module, which is separate from the major version so you can be confident that you can upgrade to get bug fixes and security patches without shocking your users.

]]> Comment on Advanced grading methods in Moodle 2.2 by Ray http://blog.mudrak.name/2011/11/advanced-grading-methods-in-moodle-2-2/comment-page-1/#comment-2223 Ray Mon, 14 Nov 2011 23:51:09 +0000 http://blog.mudrak.name/?p=415#comment-2223 Nice work all. And of course, the supplementary question.... :) When do you expect the next plugins to land? Nice work all. And of course, the supplementary question…. :) When do you expect the next plugins to land?

]]> Comment on Advanced grading methods in Moodle 2.2 by Eloy Lafuente (stronk7) http://blog.mudrak.name/2011/11/advanced-grading-methods-in-moodle-2-2/comment-page-1/#comment-2222 Eloy Lafuente (stronk7) Mon, 14 Nov 2011 16:03:40 +0000 http://blog.mudrak.name/?p=415#comment-2222 Congrats Team! Great work all! PS: let's schedule one chat to discuss about backup and restore 2.x, grr, lol. Congrats Team! Great work all!

PS: let’s schedule one chat to discuss about backup and restore 2.x, grr, lol.

]]> Comment on Moodle development traffic 7/2011 by dwebber http://blog.mudrak.name/2011/02/moodle-development-traffic-72011/comment-page-1/#comment-2220 dwebber Thu, 20 Oct 2011 21:22:54 +0000 http://blog.mudrak.name/?p=402#comment-2220 can people respond to others' blogs on moodle yet? so far, in the interface, i don't see where a person would be able to do that. can people respond to others’ blogs on moodle yet?

so far, in the interface, i don’t see where a person would be able to do that.

]]> Comment on Moodle development traffic 7/2011 by mudrd8mz http://blog.mudrak.name/2011/02/moodle-development-traffic-72011/comment-page-1/#comment-2129 mudrd8mz Fri, 18 Feb 2011 22:18:21 +0000 http://blog.mudrak.name/?p=402#comment-2129 [New Post] Moodle development traffic 7/2011 - via #twitoaster http://blog.mudrak.name/2011/02/moodle-d... [New Post] Moodle development traffic 7/2011 – via #twitoaster http://blog.mudrak.name/2011/02/moodle-d...

]]> Comment on Moodle development traffic 5/2011 by David http://blog.mudrak.name/2011/02/moodle-development-traffic-52011/comment-page-1/#comment-2127 David Fri, 18 Feb 2011 20:21:21 +0000 http://blog.mudrak.name/?p=384#comment-2127 Esteve - there is still an issue though mentioned in my post. You can't have nested block elements within this span (see http://www.w3.org/TR/REC-html40/struct/global.html#block-inline). Also, you can't start your CONTENT block in the middle of paragraph and end in the middle of the next paragraph. Esteve – there is still an issue though mentioned in my post. You can’t have nested block elements within this span (see http://www.w3.org/TR/REC-html40/struct/global.html#block-inline). Also, you can’t start your CONTENT block in the middle of paragraph and end in the middle of the next paragraph.

]]> Comment on Moodle development traffic 5/2011 by Esteve http://blog.mudrak.name/2011/02/moodle-development-traffic-52011/comment-page-1/#comment-2062 Esteve Tue, 08 Feb 2011 12:23:18 +0000 http://blog.mudrak.name/?p=384#comment-2062 Hello again: The preceeding post has a pair of encoding errors: where says "CONTENT" it should say "<span class="nolink"&gt>CONTENT</span&gt", and were says "also the tag" it should read "also the <nolink> tag". – Esteve Badia Maths for More – WIRIS Hello again:
The preceeding post has a pair of encoding errors:
where says “CONTENT” it should say “<span class=”nolink”&gt>CONTENT</span&gt”,
and were says “also the tag” it should read “also the <nolink> tag”.

–

Esteve Badia
Maths for More – WIRIS

]]> Comment on Moodle development traffic 5/2011 by Esteve http://blog.mudrak.name/2011/02/moodle-development-traffic-52011/comment-page-1/#comment-2061 Esteve Tue, 08 Feb 2011 12:16:03 +0000 http://blog.mudrak.name/?p=384#comment-2061 Hello David, We were working about this "nolink" issue several months ago. We made a simple algorithm that works with the syntax CONTENT, and supports nested tags, malformed html, and also the tag. It doesn't parse the HTML. It uses only search & replace so it has linear time cost and constant memory cost. The patch is published at http://tracker.moodle.org/browse/MDL-21721, the track still being oppened. Best Regards, -- Esteve Badia Maths for More - WIRIS Hello David,
We were working about this “nolink” issue several months ago. We made a simple algorithm that works with the syntax CONTENT, and supports nested tags, malformed html, and also the tag. It doesn’t parse the HTML. It uses only search & replace so it has linear time cost and constant memory cost.

The patch is published at http://tracker.moodle.org/browse/MDL-21721, the track still being oppened.

Best Regards,

–

Esteve Badia
Maths for More – WIRIS

]]>