Moodle Community Sites

How to deal with 3rd Party Software Versions in CVS

Details

  • Type: Task Task
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Component/s: download.moodle.org
  • Labels:
    None

Description

I'm currently working on CONTRIB-836 (and CONTRIB-835). I'm wondering how best to deal with the situation in terms of which directories to create. If I create separate projects for the different version of DimDim then we do not have to do any work to get the auto-generated zip files for download because there would be two projects. However, if we want to treat them as one project with two versions (i.e. contrib/plugins/mod/dimdim/40 and contrib/plugins/mod/dimdim/45) that would allow the contributors to develop and maintain their own versioning at will; however, we will then need to look at the script so that it auto-generates the zip files. I was looking for recommendations on how we want to handle this. I think ideally we treat it as one project with multiple versions rather than each version as a separate project but I'm not convinced that that will be practical. Thanks for any words of wisdom. Peace - Anthony

Issue Links

Activity

Hide
Eloy Lafuente (stronk7) added a comment -

Yup, reallly that's a problem.

1) My first thought was about to have only the contrib/plugins/mod/dimdim project and, there, create separate folders for different subprojects (dimdim40, dimdim45) and a BIG README noting about how to install that "special" module. I could be something like:

contrib/plugins/mod/dimdim

  • README.txt
  • dimdim40
  • dimdim
  • dimdim45
  • dimdim

That way we could keep the standard packaging and people can use the correct dimdim module (by copying no the whole dimdim but the sub one to their moodle/mod folder. That properly explained in the README.txt file. This will allow, too, to keep both versions development 100% separated.

But this has a BIG problem and it's how people can switch from one module to the other. I can imagine one REAL situation where I'm using the dimdim40 (as mod/dimdim) and I want to switch to dimdim45 (without losing current activities and so). That will be a pain! 100% guaranteed if there are two modules called the same.

2) So then, I thought that perhaps having 100% separated (and named) modules was better. Something like:

contrib/plugins/mod

  • dimdim40
  • dimdim45

But this doesn't solve the problem either, mainly because it "forces" tables to be called "dimdim40_whatever" and "dimdim45_whatever" causing modules not being interchangeable.

3) So, definitively.... the only possible way to handle this, keeping interchangeability, proper packaging and functionality... is this structure:

contrib/plugins/mod/dimdim (i.e. the standard one).

With only ONE module, able to work with both 4.0 and 4.5 dimdim servers (perhaps that needs to be a preference in the module, not sure about that). But, for sure, it's the only way that will allow everybody to enjoy using Dimdim (making that the unique module itself was able to support both servers). I know this is all about dimdim developers and they must agree (and program). But, in the long term, it's the only viable way to make it work. 1 module, able to work against multiple dimdim versions.

So, IMO, 3) is the option to follow. Everything else will cause problems upgrading/installing/packaging. And user experience won't be good (not the developers one, having to apply changes in different code bases to fix bugs, change DB versions, etc, etc). One module-code-base to root all them, definetively.

Hope this helps, ciao

Show
Eloy Lafuente (stronk7) added a comment - Yup, reallly that's a problem. 1) My first thought was about to have only the contrib/plugins/mod/dimdim project and, there, create separate folders for different subprojects (dimdim40, dimdim45) and a BIG README noting about how to install that "special" module. I could be something like: contrib/plugins/mod/dimdim
  • README.txt
  • dimdim40
  • dimdim
  • dimdim45
  • dimdim
That way we could keep the standard packaging and people can use the correct dimdim module (by copying no the whole dimdim but the sub one to their moodle/mod folder. That properly explained in the README.txt file. This will allow, too, to keep both versions development 100% separated. But this has a BIG problem and it's how people can switch from one module to the other. I can imagine one REAL situation where I'm using the dimdim40 (as mod/dimdim) and I want to switch to dimdim45 (without losing current activities and so). That will be a pain! 100% guaranteed if there are two modules called the same. 2) So then, I thought that perhaps having 100% separated (and named) modules was better. Something like: contrib/plugins/mod
  • dimdim40
  • dimdim45
But this doesn't solve the problem either, mainly because it "forces" tables to be called "dimdim40_whatever" and "dimdim45_whatever" causing modules not being interchangeable. 3) So, definitively.... the only possible way to handle this, keeping interchangeability, proper packaging and functionality... is this structure: contrib/plugins/mod/dimdim (i.e. the standard one). With only ONE module, able to work with both 4.0 and 4.5 dimdim servers (perhaps that needs to be a preference in the module, not sure about that). But, for sure, it's the only way that will allow everybody to enjoy using Dimdim (making that the unique module itself was able to support both servers). I know this is all about dimdim developers and they must agree (and program). But, in the long term, it's the only viable way to make it work. 1 module, able to work against multiple dimdim versions. So, IMO, 3) is the option to follow. Everything else will cause problems upgrading/installing/packaging. And user experience won't be good (not the developers one, having to apply changes in different code bases to fix bugs, change DB versions, etc, etc). One module-code-base to root all them, definetively. Hope this helps, ciao
Hide
Anthony Borrow added a comment -

I've added Rajesh as a watcher to this issue and just sent him an email. It seems to me that we may work around this if they require that their users upgrade to the current stable version. I think by limiting what is supported we could just use HEAD as their latest development version and what is stored in MOODLE_19_STABLE would be for the current stable release of their server. Here is what I wrote to Rajesh after he responded to my question about their typical release cycle which is about every 3 months or so:

Rajesh - Is there backward compatibility? I know that there is the DimDim server and then the client side. What expectations do you have from users when a new server version comes out? If I recall things are not backward compatible. For example, when you upgraded the DimDim server to 4.0, I believe the JVLA site was required to upgrade its Moodle activity to the 4.0 version. Since your release cycle is significantly more frequent than Moodle's and since you generally want folks using the latest version of your software, I'm inclined to think that perhaps having you work with a single version in Moodle CONTRIB would be best but have two branches, the current one (in this case 4.0) and the development one (4.5). When 4.5 becomes released then it will replace it in the 19_STABLE branch and the new development version (say, 5.0 will then be developed in HEAD). Might that work for you? Just as you require and only support that a particular version of DimDim be used you may also want to limit which versions of Moodle you support; however, if you wanted to maintain a separate 18_STABLE version you could but that it would be simply for the current stable release of DimDim. I think this may be a case of where limiting the support you offer and the number of options may be to everyone's benefit. Does that make sense? What might be some of the drawbacks or problems for you or your users with this approach? Peace - Anthony

Show
Anthony Borrow added a comment - I've added Rajesh as a watcher to this issue and just sent him an email. It seems to me that we may work around this if they require that their users upgrade to the current stable version. I think by limiting what is supported we could just use HEAD as their latest development version and what is stored in MOODLE_19_STABLE would be for the current stable release of their server. Here is what I wrote to Rajesh after he responded to my question about their typical release cycle which is about every 3 months or so: Rajesh - Is there backward compatibility? I know that there is the DimDim server and then the client side. What expectations do you have from users when a new server version comes out? If I recall things are not backward compatible. For example, when you upgraded the DimDim server to 4.0, I believe the JVLA site was required to upgrade its Moodle activity to the 4.0 version. Since your release cycle is significantly more frequent than Moodle's and since you generally want folks using the latest version of your software, I'm inclined to think that perhaps having you work with a single version in Moodle CONTRIB would be best but have two branches, the current one (in this case 4.0) and the development one (4.5). When 4.5 becomes released then it will replace it in the 19_STABLE branch and the new development version (say, 5.0 will then be developed in HEAD). Might that work for you? Just as you require and only support that a particular version of DimDim be used you may also want to limit which versions of Moodle you support; however, if you wanted to maintain a separate 18_STABLE version you could but that it would be simply for the current stable release of DimDim. I think this may be a case of where limiting the support you offer and the number of options may be to everyone's benefit. Does that make sense? What might be some of the drawbacks or problems for you or your users with this approach? Peace - Anthony
Hide
Anthony Borrow added a comment -

Eloy - Keep in mind that I'm thinking out loud here and trying to see how this might work. I'm wondering how we might resolve this using branches to maintain separate code bases for each version without screwing up the zip files. I'm thinking along the lines of branches and tweaking how the zip files are created but I'm hoping it would not be too complicated. So for example, I envision /plugins/mod/dimdim having 4 branches:

MOODLE_19_STABLE_40 (Moodle version branch _x where x is some text (I was originally thinking number but see no reason to limit it to version numbers as I thought of the example of Elluminate code which has an elm and sas version)
MOODLE_19_STABLE_45
HEAD_40
HEAD_45

The download links could then look something like:

http://download.moodle.org/download.php/plugins19_40/mod/dimdim.zip
http://download.moodle.org/download.php/plugins19_45/mod/dimdim.zip
http://download.moodle.org/download.php/plugins_40/mod/dimdim.zip
http://download.moodle.org/download.php/plugins19_45/mod/dimdim.zip

I realize that there may also be the standard branches MOODLE_19_STABLE and HEAD that would continue to generate:

http://download.moodle.org/download.php/plugins19/mod/dimdim.zip
http://download.moodle.org/download.php/plugins/mod/dimdim.zip

I would say that if the external program's version is not attached then that would be used for their equivalent of HEAD or their development version. One question I would have in this scenario is would the MOODLE_19_STABLE and HEAD branches be required in order to get the other branches to auto-generate? In other words could we have a plugin that only had for example
MOODLE_19_STABLE_40, MOODLE_19_STABLE_45, HEAD_40, and HEAD_45 branches (I suspect yes).

The next piece to this puzzle would be figuring out packages and allowing something similar for packages. As an example their I'm looking at the Elluminate integrations which are currently (incorrectly IMO) listed under patches.

If finding the last _section is problematic we could use a different character - perhaps a dash. I'm not sure how you check the branches with the script. In any case, I would appreciate your thoughts, concerns, questions, ideas, etc.

Peace - Anthony

Show
Anthony Borrow added a comment - Eloy - Keep in mind that I'm thinking out loud here and trying to see how this might work. I'm wondering how we might resolve this using branches to maintain separate code bases for each version without screwing up the zip files. I'm thinking along the lines of branches and tweaking how the zip files are created but I'm hoping it would not be too complicated. So for example, I envision /plugins/mod/dimdim having 4 branches: MOODLE_19_STABLE_40 (Moodle version branch _x where x is some text (I was originally thinking number but see no reason to limit it to version numbers as I thought of the example of Elluminate code which has an elm and sas version) MOODLE_19_STABLE_45 HEAD_40 HEAD_45 The download links could then look something like: http://download.moodle.org/download.php/plugins19_40/mod/dimdim.zip http://download.moodle.org/download.php/plugins19_45/mod/dimdim.zip http://download.moodle.org/download.php/plugins_40/mod/dimdim.zip http://download.moodle.org/download.php/plugins19_45/mod/dimdim.zip I realize that there may also be the standard branches MOODLE_19_STABLE and HEAD that would continue to generate: http://download.moodle.org/download.php/plugins19/mod/dimdim.zip http://download.moodle.org/download.php/plugins/mod/dimdim.zip I would say that if the external program's version is not attached then that would be used for their equivalent of HEAD or their development version. One question I would have in this scenario is would the MOODLE_19_STABLE and HEAD branches be required in order to get the other branches to auto-generate? In other words could we have a plugin that only had for example MOODLE_19_STABLE_40, MOODLE_19_STABLE_45, HEAD_40, and HEAD_45 branches (I suspect yes). The next piece to this puzzle would be figuring out packages and allowing something similar for packages. As an example their I'm looking at the Elluminate integrations which are currently (incorrectly IMO) listed under patches. If finding the last _section is problematic we could use a different character - perhaps a dash. I'm not sure how you check the branches with the script. In any case, I would appreciate your thoughts, concerns, questions, ideas, etc. Peace - Anthony
Hide
Jonathan Moore added a comment -

Anthony asked if I would comment on this.

I am a fan of the one module concept. I would have to check with Justin Fillip but I am pretty sure this is how we have been maintaining the Elluminate bridge. We just add the new features required to detect and handle the new versions but do in a way to keep backwards compatible with the prior support version(s. Not sure if there is a technical issue with doing that for DimDim's API, but its made Elluminate module support and deployment a lot easier for us.

Show
Jonathan Moore added a comment - Anthony asked if I would comment on this. I am a fan of the one module concept. I would have to check with Justin Fillip but I am pretty sure this is how we have been maintaining the Elluminate bridge. We just add the new features required to detect and handle the new versions but do in a way to keep backwards compatible with the prior support version(s. Not sure if there is a technical issue with doing that for DimDim's API, but its made Elluminate module support and deployment a lot easier for us.
Hide
Anthony Borrow added a comment -

I would like to come to a definitive way of dealing with these types of situations so that I can move forward on the related issues. I am a fan of having everything in one directory with instructions for dealing with older systems if they exist but presuming that the majority of folks are using the latest version of the 3rd party software. Peace - Anthony

Show
Anthony Borrow added a comment - I would like to come to a definitive way of dealing with these types of situations so that I can move forward on the related issues. I am a fan of having everything in one directory with instructions for dealing with older systems if they exist but presuming that the majority of folks are using the latest version of the 3rd party software. Peace - Anthony

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated: